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Description 

[0001 ] The present invention relates to a protocol sen- 
sor which automatically determines which of several dif- 
ferent protocols is active on a computerized local area 
network, and which also determines which of several dif- 
ferent frame packet types is being used by that protocol. 
[0002] EP-A-0598513 (Representative's reference 
2274430) corresponding to U.S. Patent Application Se- 
rial No. 07/978,369, entitled "Method And Apparatus For 
Interfacing A Peripheral To A Local Area Network", is 
hereby incorporated by reference. 
[0003] Computerized local and wide area networks 
are now commonly used for providing communication 
between different computers and computer peripherals 
which are connected to the network. Communication on 
the network is carried out under control of network soft- 
ware which is now available from several different soft- 
ware manufacturers. Each of those manufacturers has 
defined a different protocol for network communication. 
Thus, Novell has defined. an IPX/SPX (internetwork 
packet exchange/sequential packet exchange) proto- 
col, UNIX operating systems have defined a TCP/IP 
(transmission control protocol/internet protocol) proto- 
col, Apple has defined an Ethertalk protocol, and other 
manufacturers have defined other network protocols. 
[0004] Each of the protocols defines how network 
communications are to be carried out, and how the net- 
work devices operating under that protocol communi- 
cate with each other. For example, protocol defines how 
a network device broadcasts requests for network serv- 
ices on the network, how it responds to requests for net- 
work services, and how it may be configured. Each of 
the protocols is incompatible with the other protocols. 
[0005] Network communications are carried on the 
physical network wire in packets which are commonly 
referred to as "frames". Several different frame types 
have been defined, and are in common use, and each 
frame type specifies the organization of network data in 
a frame, such as the length of the frame packet, error 
codes for the frame packet, location of source and des- 
tination sockets, and the like. Examples of frame types 
in an Ethernet network are 802.2, EthernetJI, 
Ethernet_Snap, and 802.3. 

[0006] Accordingly, to communicate on a network, it 
is necessary to know both the protocol in use by the net- 
work software and the frame packet type with which net- 
work communications are carried on the physical net- 
work wire. 

[0007] As sophistication of computerized networks 
has grown, it is also common to encounter networks on 
which two or more different protocols are being run, 
each with its own frame packet type. For example, it is 
common to encounter a network on which both a Novell 
IPX/SPX protocol is being run using, for example, an 
802.2 frame type, as well as a UNIX TCP/IP protocol 
using, for example, an EthernetJI frame packet type. 
Modern network devices must therefore be able to com- 



municate effectively on multi-protocol networks. 
[0008] This multi-protocol requirement has given rise 
to the following problem. Each of the different protocols 
ordinarily involves some sort of network broadcast by 
5 which the network device advises all devices connected 
to the network that it is connected to the network. For 
example, a Novell IPX/SPX protocol involves SAP 
(service advertising packages) broadcasts by which the 
network device advertises the availability of its services. 
10 Similarly, a UNIX TCP/IP protocol involves a RARP (re- 
verse address resolution protocol) broadcast by which 
the TCP/IP device broadcasts a request for a network 
address. One way that has been considered to deter- 
mine whether a particular protocol is active on the net- 
's work is to make a broadcast request and see if any de- 
vice responds. However, broadcasting on a network that 
is not prepared to respond to such broadcasts may 
cause network difficulties. In extreme cases, broadcast- 
ing in an unexpected protocol may ultimately cause a 
20 no n -robust network to malfunction. 

[0009] The aforementioned problem is addressed by 
the present invention in which protocol is detected with- 
out broadcasting network requests. 
[001 0] According to a first aspect of the present inven- 
ts tion, there is provided a method of determining which of 
a plurality of protocols is used on a network, comprising 
the steps of: executing a link support layer module so 
as to monitor network communications for broadcast 
frame packets, said link support layer module being 
30 adapted to accept registrations for any one of a plurality 
of frame types; registering each of the plurality of frame 
types with said link support layer module; receiving from 
said link support layer module a frame packet which 
matches a first one of the frame types; and decoding 
35 header information in the received frame packet so as 
to determine which protocol is used by the frame packet, 
the method being characterised by the steps of: de-reg- 
istering the first frame type from said link support layer 
module, said step of de-registering not being performed 
*o in the case where the first frame type is an allowable 
frame type for a protocol stack not already registered 
with said link support layer module; initializing a first pro- 
tocol stack corresponding to the determined protocol by 
using the first frame type; loading the first protocol stack; 
45 and registering the first protocol stack with said link sup- 
port layer module so that the first protocol stack receives 
future frame packets which match the first frame type. 
[0011] According to a second aspect of the present 
invention, there is provided a networkable device in 
so which each of a plurality of different protocol stacks com- 
municate on a network via a common link support layer 
module, comprising: a memory for storing process 
steps, the process steps including process steps com- 
prising said link support layer module and process steps 
55 comprising said plural different protocol stacks; and a 
processor for executing the process steps stored in said 
memory, wherein the process steps further include proc- 
ess steps to register each of said plural different protocol 
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stacks with said link support layer module by: monitoring 
using said link support layer module network communi- 
cations for broadcast frame packets, said link support 
layer module being adapted to accept registrations for 
any one of plural frame types; registering each of the 
plural frame types with said link support layer module; 
receiving from said link support layer module a frame 
packet which matches a first one of the frame types; and 
decoding header information in the received frame 
packet so as to determine which protocol is used by the 
frame packet, the device being characterised by the 
processor executing the process steps of: de-register- 
ing the first frame type from said link support layer mod- 
ule, said step of de-registering not being performed in a 
case where the first frame type is an allowable frame 
type for a protocol stack not already registered with said 
link support layer module; initializing a first protocol 
stack corresponding to the determined protocol by using 
the first frame type; loading the first protocol stack; and 
registering the first protocol stack with said link support 
layer module so that the first protocol stack receives fu- 
ture frame packets which match the first frame type. 
[0012] According to a third aspect of the present in- 
vention, there are provided computer executable proc- 
ess steps for determining which of a plurality of different 
protocols is used on a network, said process steps com- 
prising: an executing step to execute a link support layer 
module so as to monitor network communications for 
broadcast frame packets, said link support layer module 
being adapted to accept registrations for any one of plu- 
ral frame types; a registering step to register each of the 
plural frame types with said link support layer module; 
a receiving step to receive from said link support layer 
module a frame packet which matches a first one of the 
frame types; and a decoding step to decode header in- 
formation in the received frame packet so as to deter- 
mine which protocol is used by the frame packet, the 
process steps being characterized by: a de-registering 
step to de-register the first frame type from said link sup- 
port layer module, said de-registering step not being 
performed in the case where the first frame type is an 
allowable frame type for a protocol stack not already 
registered with said link support layer module; an initial- 
izing step to initialize a first protocol stack corresponding 
to the determined protocol by using the first frame type; 
a loading step to load the first protocol stack; and a reg- 
istering step to register the first protocol stack with said 
link support layer module so that the first protocol stack 
receives future frame packets which match the first 
frame type. 

[0013] By virtue of this arrangement, protocol is auto- 
matically determined without making needless broad- 
casts. Moreover, because LSL continues to hold regis- 
trations for as-yet- inactive frame types, even if a second 
protocol becomes active well into a power-on cycle, that 
second protocol is also automatically detected. 
[0014] In a particularly preferred embodiment of the 
invention, protocol sensing is utilized in the context of a 



4 

network board which exports the functionality of a printer 
onto a local area network. According to this preferred 
embodiment, the network board may sit passively ob- 
serving network traffic without broadcasting any re- 

s quests which might disrupt the network. Then, in re- 
sponse to detection of a protocol being used on the net- 
work, the network board may commence broadcasting 
network communications in the detected protocol. In ad- 
dition, as future protocols are detected, such as in amul- 

10 ti-protocol system, the network board may also respond 
to those other protocols and begin broadcasting re- 
quests for those other protocols. 
[0015] This brief summary has been provided so that 
the nature of the invention may be understood quickly. 

is A more complete understanding of the invention can be 
obtained by reference to the following detailed descrip- 
tion of the preferred embodiment thereof in connection 
with the attached drawings. 

20 BRIEF DESCRIPTION OF THE DRAWINGS 

[0016] Figure 1 is a diagram of a local area network 
and wide area network to which a network board is cou- 
pled. 

25 [0017] Figure 2 is a cut-away perspective view of the 
network board fitted into a Canon LBP 1260 laser print- 
er. 

[0018] Figure 3 is a block diagram showing the net- 
work board coupled between a printer and a local area 
30 network. 

[001 9] Figure 4 is a diagram showing the physical lay- 
out of components on the network board. 
[0020] Figure 5 is a drawing of a face plate for the net- 
work board. 

35 [0021] Figure 6 is a functional block diagram of the 
network board. 

[0022] Figure 7 is a diagram showing examples of 
several software modules that may be stored in the flash 
EPROM. 

40 [0023] Figure 8 is a block diagram of an arrangement 
used to determine which connector is connected to the 
network. 

[0024] Figure 9 is a flowchart showing how to detect 
which connector is connected to the network. 
45 [0025] Figure 1 0 is a flow chart showing the operation 
of a PRETASK software module. 
[0026] Figures 11(a) through 11(d) are diagrams 
showing possible relationships of various network soft- 
ware modules. 

so [0027] Figure 12 is a block diagram showing a PC 
connected to a Ethernet local area network and a Token- 
ring local area network. 

[0028] Figure 13 is a diagram showing contents of a 
network information file block used for storing configu- 
55 ration information. 

[0029] Figure 14 is a flowchart showing reprogram- 
ming of flash EPROM. 

[0030] Figure 15 is a block diagram of a memory ar- 
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bitration device. 

[0031] Figure 16 is a block diagram of one preferred 
construction of a shared memory arbiter in the arbitra- 
tion device. 

[0032] Figure 1 7 is a diagram showing the timing of s 
signals provided to the arbitration device. 
[0033] Figure 1 8 is a diagram showing the configura- 
tion of shared memory. 

[0034] Figure 19 is a flowchart showing the operations 
involved in writing into shared memory. 
[0035] Figure 20 is a flowchart showing operations in- 
volved in reading from shared memory. 
[0036] Figures 21(a) through 21(c) show various al- 
ternatives for configuring shared memory. 
[0037] Figure 22 is a block diagram of a serial port. 
[0038] Figures 23(a) and 24(a) are flowcharts show- 
ing operations involved in receiving and sending serial 
communications over the serial port. 
[0039] Figures 23(b) and 24(b) are diagrams showing 
the timing of signals in the serial receive and send 
modes. 

DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENT 

[0040] In its most preferred form, the present inven- 
tion is embodied in a network board (or "NEB") which 
provides hardware, software and firmware solutions for 
making a network peripheral, such as a printer, an intel- 
ligent, interactive network member, capable not only of 
receiving and processing data from the network, but al- 
so of transmitting to the network significant amounts of 
data about the peripheral such as detailed status infor- 
mation, operational parameters and the like. It is also 
possible to use the invention in other networked periph- 
erals such as scanning, facsimile, copier, image 
processing and other such peripherals. Integration of 
such hardware, software and firmware with the periph- 
eral eliminates the need to dedicate a personal compu- 
ter to act as a peripheral server. 

[Network Architecture] 

[0041] Figure 1 is a diagram showing the present in- 
vention incorporated into a NEtwork Board (NEB) 101 
coupled to a printer 102 having an open architecture. 
NEB 101 is coupled to local area network (LAN) 100 
through a LAN interface, for example, an Ethernet inter- 
face 1 0Base-2 with a Coax connector or 1 0Base-T with 
an RJ-45 connector. 

[0042] Plural personal computers (PCs), such as PCs 
1 03 and 1 04, are also connected to LAN 1 00, and under 
control of the network operating system these PCs are 
able to communicate with NEB 101. One of the PCs, 
such as PC 103, may be designated for use as the net- 
work administrator. A PC may have a printer connected 
to it, such as printer 105 connected to PC 104. 
[0043] Also connected to LAN 100 is file server 1 06 



which manages access to files stored on a large capac- 
ity (e.g., 10 gigabyte) network disk 107. A print server 
1 08 provides print services to printers 1 09 and 1 1 0 con- 
nected to it, as well as to remote printers such as printer 
1 05. Other unshown peripherals may also be connected 
to LAN 100. 

[0044] In more detail, the network depicted in Figure 
1 may utilize any network software such as Novell or 
UNIX software in order to effect communication among 
the various network members. The present embodi- 
ments will be described with respect to a LAN utilizing 
Novell NetWare® software, although any network soft- 
ware could be used. A detailed description of this soft- 
ware package may be found in "NetWare® User's 
Guide" and "NetWare® Supervisor's Guide", published 
by M&T Books, copyrighted 1990, incorporated herein 
by reference. See also the "NetWare® Printer Server" 
by Novell, March 1991 edition, Novell Part No. 
100-000892-001. 

[0045] Briefly, file server 106 acts as a file manager, 
receiving, storing, queuing, caching, and transmitting 
files of data between LAN members. For example, data 
files created respectively at PCs 103 and 104 may be 
routed to file server 1 06 which may order those data files 
and then transfer the ordered data files to printer 109 
upon command from print server 1 08. 
[0046] PCs 1 03 and 1 04 may each comprise a stand- 
ard PC capable of generating data files, transmitting 
them onto LAN 100, receiving files from LAN 100, and 
displaying and/or processing such files. However, while 
personal computer equipment is illustrated in Figure 1, 
other computer equipment may also be included, as ap- 
propriate to the network software being executed. For 
example, UNIX workstations may be included in the net- 
work when UNIX software is used, and those worksta- 
tions may be used in conjunction with the illustrated 
PC's under appropriate circumstances. 
[0047] Typically, a LAN such as LAN 100 services a 
fairly localized group of users such as a group of users 
on one floor or contiguous floors in a building. As users 
become more remote from one another, for example, in 
different buildings or different states, a wide area net- 
work (WAN) may be created which is essentially a col- 
lection of several LANs all connected by high speed dig- 
ital lines, such as high speed integrated services digital 
network (ISDN) telephone lines. Thus, as shown in Fig- 
ure 1 , LANs 1 00, 110 and 120 are connected to form a 
WAN via modulator/demodulator (MODEM)/transpond- 
er 130 and backbone 140, which is simply an electrical 
connection between several buses. Each LAN includes 
its own PCs, and each ordinarily includes its own file 
server and print server, although that is not necessarily 
the case. 

[0048] Thus, as shown in Figure 1 , LAN 110 includes 
PCs 1 1 1 and 112, file server 113, network disk 1 1 4, print 
server 115 and printers 116 and 117. LAN 120, on the 
other hand, includes only PCs 121 and 122. Via WAN 
connections, equipment in any of LANs 100, 110 and 
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1 20 can access the capabilities of equipment in any oth- 
er of the LANs. 

[0049] PC 104 may be embedded with an RPRINTER 
software program, and as such may exert limited control 
over network peripherals. The RPRINTER program is 
an MS-DOS terminate-and-stay- resident ("TSR") pro- 
gram which allows users to share printer 1 05 connected 
to PC 104 while at the same time allowing PC 104 to 
execute other non-print applications. RPRINTER is a 
relatively unintelligent program that does not have the 
ability to search printer queues for work. RPRINTER 
gets its work from print server 1 08 running elsewhere in 
the network. Because it communicates with the at- 
tached printer over the printer's parallel port, PC 1 04 
running RPRINTER is able to obtain only limited status 
information from printer 1 05 and to return that status in- 
formation to print server 1 08 over LAN 1 00. From a con- 
trol standpoint, RPRINTER allows stopping of a print job 
(when, for example, the printer is out of paper or off-line) 
and little more. Some printers include RPRINTER fea- 
tures by offering internal or external circuit boards that 
provide the same limited features of the RPRINTER 
TSR program running in a personal computer. 
[0050] Print server 1 08 is capable of exercising more 
significant control over LAN peripherals but requires a 
dedicated PC which cannot be used for any other task. 
Print server 108, which may itself be a PC, has the ability 
to service multiple user-defined print queues, perform 
dynamic search queue modification, and provide de- 
fined notification procedures for exception (failure) con- 
ditions and status and control capabilities, and can con- 
trol both local printers 1 09 and 1 1 0 (that is, printers phys- 
ically connected to print server 108) and remote printers. 
Local printers 109 and 110 can be connected to either 
serial or parallel ports, and the remote printers, such as 
printer 1 05, are printers running elsewhere in the system 
which print server 1 08 controls through RPRINTER soft- 
ware. 

[0051] Print server 108 can control many local or re- 
mote printers and can request print information from 
many file server queues. However, there are several 
drawbacks to relying on print server 108 to control net- 
work printing services. A first drawback is that multiple 
printer streams must all be funnelled through a single 
network node. This can become a bottleneck. A second 
drawback is that for the most efficient operation, the 
printers should be connected to the print server locally, 
like printers 1 09 and 110. This can be an inconvenience 
for users since it requires the printers to be clustered 
around print server 1 08 and also requires users to travel 
to those clustered printers. A third drawback is that if the 
controlled printers are remote, as in the case of printer 
105 which is serviced by RPRINTER, then print data 
must make several trips, first from file server 1 06 to print 
server 1 08, and then from print server 1 08 to the printer 
running RPRINTER. This is inefficient. 
[0052] A fourth drawback is the limited amount of 
printer status and control information offered through 



print server 108. It has already been stated that 
RPRINTER does not allowfor much more than rudimen- 
tary status information such as "out of paper*' and "off 
line". Print server 1 08 does not offer more than this be- 
5 cause it was designed with consideration of the limita- 
tions of the personal computer parallel port. 

(The Network Board] 

w [0053] Installation of NEB 101 into printer 102 pro- 
vides many advantages over the network peripheral 
control entities discussed above, in that it allows printer 
1 02 to become an intelligent, interactive network mem- 
ber. 

is [0054] As shown in Figure 2, NEB 101 is preferably 
housed in an internal expansion I/O slot of printer 102, 
which in a preferred embodiment of the present inven- 
tion is a Canon LBP 1260 laser printer. This makes NEB 
101 an embedded network node having the processing 

20 and data storage features described below. 

[0055] The architecture of NEB 101 provides an ad- 
vantage in that it has unique support features for admin- 
istration and management of large, multi-area WAN net- 
works. These support features could include, for exam- 

25 pie, printer control and status monitoring from a remote 
location on the network (such as from the network ad- 
ministrator's office), automatic management of printer 
configuration after each print job to provide a guaran- 
teed initial environment for a next user, and printer logs 

30 or usage statistics accessible across the network for 
characterizing printer workload and scheduling toner 
cartridge replacement. 

[0056] An important parameter in the NEB design is 
the ability to access the printer control state from NEB 

35 101 through a bi-directional interface, here a shared 
memory, although other bi-directional interfaces such as 
SCSI interfaces are also possible. This allows printer 
console information to be exported to NEB 1 01 or to an 
external network node so as to allow programming of 

40 many useful support functions. Blocks of print image da- 
ta and control information are assembled by a micro- 
processor on board NEB 101 , they are written into the 
shared memory, and they are then read by printer 102. 
Likewise, printer status information is transferred from 

45 printer 1 02 to the shared memory, from where it is read 
by the NEB microprocessor. 

[0057] Figure 2 is a cut-away perspective view show- 
ing installation of NEB 101 into printer 102. As seen in 
Figure 2, NEB 1 01 , which is constructed from a printed 

so circuit board 1 01 a on which is mounted face plate 101b 
which allows for network connections, is connected via 
connector 170 to printer interface card 150. As de- 
scribed below, printer interface card 150 directly con- 
trols the print engine in printer 1 02. Print data and printer 

55 status commands are fed to printer interface card 150 
from NEB 101 via connector 170, and printer status in- 
formation is obtained from card 150 also via connector 
170. NEB 101 communicates this information onto LAN 
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100 via the network connectors on face plate 101b. At 
the same time, printer 1 02 can also receive print data 
from conventional serial port 102a and parallel port 
102b. 

[0058] Figure 3 is a block diagram depicting electrical 
connection of NEB 101 to printer 102. NEB 101 is di- 
rectly connected to LAN 1 00 via a LAN interface, and to 
printer 1 02 via printer interface card 1 50. In a preferred 
embodiment of the invention, the printer interface card 
150 is a Peerless LBP-860/1 260- External Standard I/O 
Board Interface, available from Peerless Systems 
Corp., the details of which can be found in the Peerless 
Standard I/O Interface Design Specification, revision 
2.07a, Peerless Systems Corp., May 10, 1994. The 
board includes an Intel 80960KB-2Q microprocessor 
151 . Although it is a 32-bit machine, microprocessor 151 
accesses data to and from NEB 101 are in 2 byte wide 
(1 6-bit) transfers via a shared memory 200 arranged on 
NEB 101 . Microprocessor 151 also communicates with 
print engine 1 60 which actually drives the printing mech- 
anism. 

[NEB Physical Layout] 

[0059] Figure 4 shows the dimensions of a preferred 
embodiment of NEB 101 and the physical layout of the 
major components thereof . The NEB card is 10.0 cm by 
14.2 cm. NEB 101 includes a printer interface card con- 
nector 1 70 (which in the case of the Peerless printer in- 
terface card is an 80-pin connector) that couples to the 
printer interface card and face plate 300 having connec- 
tors 301 and 302 that allow connection to LAN 1 00. The 
face plate also includes 4 status light emitting diodes 
(LEDs) 303-306. Arranged on the NEB card are trans- 
ceiver 171, crystal oscillator 1 72, microprocessor 1 73, 
arbiter control logic 400, flash erasable programmable 
read only memory (EPROM) 174, dynamic random ac- 
cess memory (DRAM) 175, first static random access 
memory (SRAM) 200, second SRAM 176, network and 
NEB control logic 500, and serial port connector 600. 
Each of these components will be discussed in greater 
detail below. 

[0060] Figure 5 depicts a more detailed view of face 
plate 300, the dimensions of which are 11.6 cm by 
3.25cm. As stated above, NEB 1 01 couples to LAN 1 00 
through connectors 301 and 302. Preferably, connector 
301 is an RJ-45 connector capable of accepting a 
10Base-T connection, while connector 302 may be a 
simple coax connector capable of accepting a 1 0Base- 
2 connection. Status LED 303 is lit when NEB 101 is 
transmitting data over LAN 100, and status LED 304 is 
lit when NEB 1 01 is receiving data from LAN 1 00. Status 
LED 305 is lit when RJ-45 connector 301 is connected 
to LAN 100, while status LED 306 is lit during self-test 
diagnostics of NEB 101. Mounting holes 307 accept 
crews for fixing NEB 101 to printer 102. 



[NEB Architecture] 

[0061 ] The architecture of NEB 1 01 is shown in Figure 
6. Power for all circuits is supplied to NEB 101 from a 

5 +5V power source 177. +5V power is also provided to 
power converters 1 78 and 1 79. Power converter 1 78 
provides -9V power to transceiver 1 71 , while power con- 
verter 179 provides +12V power to flash EPROM 174 
for "flashing" (i.e., reprogramming of the EPROM). 

w [0062] Network and NEB control logic 500 is prefera- 
bly a single 1 44-pin application specific integrated circuit 
(ASIC) that includes a network controller 510 and NEB 
control logic 520. Network controller 510 is an NCR 
macro-cell compatible with National DP83902A 

15 "ST-NIC" Ethernet controller, the details of which can be 
found in National Semiconductor's Local Area Networks 
Databook, National Semiconductor p/n 400055, Nation- 
al Semiconductor, 1993. Network controller 510 is de- 
signed to interface with CSMA/CA-type (carrier sense 

20 multiple access with collision detection) local area net- 
works. 

[0063] Network controller 510 connects with RJ-45 
connector 301 directly and with coaxial connector 302 
through transceiver 1 71 , which is preferably a National 

25 Semiconductor DP8392 coaxial transceiver interface, 
the details of which can also be found in National's Local 
Area Networks Databook. Network controller 51 0 is also 
coupled to an 8KB SRAM 1 76 that is used as an input/ 
output packet buffer for Ethernet data. This memory 

30 should preferably have an access time of about 70 ns 
or less. 

[0064] NEB control logic 520 provides an interface be- 
tween network controller 510, microprocessor 173, and 
memory devices EPROM 174 and DRAM 175. NEB 

35 control logic 520 also interfaces with non-volatile ran- 
dom access memory (NVRAM) 1 80, which is a 256 byte 
serial electrically erasable/programmable memory used 
for initialization data storage during power cycling of 
printer 1 02 which houses NEB 1 01 . Network and printer 

40 configuration parameters are written into NVRAM 1 80 
when the printer is first installed onto the network to al- 
low NEB software to recover the installation parameters 
after printer power has been cycled off and on. 
[0065] NEB control logic 520 also couples with serial 

45 port connector 600, which comprises a receive data pin 
601 and a transmit data pin 602 that can respectively 
receive and transmit serial data streams for debugging 
purposes. NEB control logic 520 senses data present at 
the receive data line and samples the serial bits at reg- 

so ular intervals, in a mannerthat will be discussed in great- 
er detail below. 

[0066] The central controller of NEB 1 01 is microproc- 
essor 1 73, preferably an Intel 80C1 88EA-20 8-bit proc- 
essor, the details of which can be found in the 
55 80C186EA/80188EA User's Manual, Intel p/n 
270950-001 , Intel Corp. This processor is an 8-bit proc- 
essor with direct memory access (DMA), interrupts, tim- 
ers, and a DRAM refresh control. Other microproces- 
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sors, such as an AMD 80C1 88-20 8-bit microprocessor, 
might alternatively be used. 256 KB flash EPROM 1 74 
and 512 KB DRAM 175 are coupled to microprocessor 
173 via NEB control logic 520, while 32 KB SRAM 200 
(which is shared with printer interface card 150) is cou- 
pled with microprocessor 173 via arbiter control logic 
400. A 40 MHz, 50 ppm crystal oscillator 172 provides 
the microprocessor with a clock signal that is wholly sep- 
arate from and asynchronous with the clock signal pro- 
vided to microprocessor 151 on printer interface card 
150. 

[0067] Microprocessor 173 executes instructions in 
flash EPROM 174, which stores control firmware and 
printing application software. After power-on self -test 
(POST), code is selectively moved to the higher per- 
formance 512 KB DRAM 175, which should preferably 
have an access time of about 80 ns, for actual execution. 
Flash EPROM 174 can be reprogrammed, or "flashed", 
from LAN 1 00, as discussed below. 
[0068] Figure 7 illustrates several examples of blocks 
of code, or modules, that are stored in flash EPROM 
1 74. The XPL module provides a standardized interface 
between printer 102 and NEB 101 . MLID (Multi Link In- 
terface Driver) is a piece of Novell code (Media Support 
Module, or MSM) linked together with a piece of cus- 
tomized code (Hardware Support Module, or HSM) that 
is the lowest level of network connection, while LSL 
(Link Support Layer) is a piece of Novell code that acts 
as a multiplexer between the low level MLID and the 
several protocol stacks above it. CNETX is customized 
code that turns local DOS-like function calls into network 
function calls, providing file functions like OPEN, READ, 
WRITE and CLOSE. 

[0069] The PRETASK module is responsible for iden- 
tifying what frame types are associated with the various 
possible protocol stacks, as described below. Because 
NEB 101 supports multiple protocol stacks, this module 
exists as long as NEB 101 is running. 
[0070] Novell's IPX/SPX protocol stack is contained 
in flash EPROM 1 74, and is supported by SAP, or Serv- 
ice Advertising Protocol. SAP is a Novell concept that 
allows devices to register themselves into the file serv- 
er's bindery, which lists active and inactive network en- 
tities. Because print servers are a special kind of bindery 
item, SAP registers NEB 101 via CPSOCKET, and if 
NEB 101 is configured as a print server, SAP also reg- 
isters the print server with the NetWare bindery. 
[0071] CPRINTSERVER is a custom implementation 
of a Novell print server application. This module pro- 
vides self-generated print banners, user notification of 
completion and exception status, and transmission of 
print data and status commands to the print engine. This 
differs from the Novell print server in that CPRINTSERV- 
ER is dedicated to driving the local printer (i.e., printer 
102 in which NEB 101 is housed) and cannot drive any 
remote R PRINTERS. This program owns the print data 
channel for the duration of a print job. RPRINTER is a 
custom implementation of a Novell RPRINTER print ap- 



plication. This module is a slave application that is sent 
data by a Novell print server application elsewhere on 
LAN 100. 

[0072] The TCP/IP protocol stack has User Datagram 

s Protocol (UDP), Reverse Address Resolution Protocol 
(RARP) and BootP support within. INTERRUPT is the 
interrupt handler for the TCP/IP task, while TIMERTICK 
is the timertickfor UNIX TCP/IP networktasks. LPRINT- 
SERVER is the TCP/IP print server application, and also 

io owns the print data channel for the duration of a print job. 
[0073] The CPSOCKET program runs for all protocol 
stacks. The program responds to requests for connec- 
tion, requests for data download, or requests for servic- 
es from remote utilities, and provides status and control 

15 to other tasks via interprocess communication. Because 
CPSOCKET typically owns the status and control chan- 
nel between NEB 1 01 and printer 1 02, it is the only task 
that has the ability to obtain printer status via the status 
channel. CPSOCKET is responsible for the network 

20 connection and packet contents between the Novell-ori- 
ented status and control utilities (CPNET), or between 
the UNIX-oriented status and control utilities (cpnet). 
[0074] MON ITOR is a customized multi -tasking mon- 
itor which performs task creation, task destruction and 

25 microprocessor dispatch. MONITOR also has memory 
management sub-modules MEMGET and MEMFREE. 
RESIDENT is a block of routines that provides generic 
services such as NVRAM read and write, FLASH code, 
ROM based debugger/hardware timer tick and other 

30 basic features. POST is a power-on self-test module 
that checks the integrity of NEB hardware and software 
at power- up. 

[0075] Flash EPROM 1 74 also stores a Network Iden- 
tification File ("NIF") block which stores board-invariant 

35 information such as the Media Access Control ("MAC") 
address, which is unique for every network board, hard- 
ware configuration, board revision number and the like, 
as well as changeable information such as software ver- 
sion number. The information in the NIF block is used 

40 to ensure that flash EPROM 174 is not reprogrammed 
with an incompatible image. The NIF block is discussed 
in greater detail below in connection with Figure 13. 
[0076] All communication between NEB 101 and 
printer interface card 150 is executed via 32 KB shared 

45 SRAM 200. Arbiter control logic 400, preferably a single 
100-pin ASIC, arbitrates between the two byte wide 
memory accesses of printer interface microprocessor 
151 and the single byte wide memory accesses of NEB 
microprocessor 173, each of which is completely inde- 

50 pendent of the other. 

[0077] Generally speaking, the 8-bit data bus of mi- 
croprocessor 173 on board NEB 101 communicates 
with bus control logic 410, while the 32-bit data bus of 
microprocessor 151 on board printer interface card 150 

55 communicates with bus control logic 420. Memory ac- 
cesses from each bus are routed to shared memory ar- 
biter 430, which determines which bus has priority (in 
accordance with an arbitration technique discussed be- 
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low) and permits the bus with priority to access SRAM 
200 via SRAM interface 440. Interrupt control register 
450 is also accessed through shared memory arbiter 
430, to allow one microprocessor to interrupt the other. 

[NEB Functionality] 

[0078] Broadly speaking, NEB 101 is an interactive 
network circuit board which couples printer 1 02 to LAN 
100, making printer 102 a responsive and interactive 
network member. NEB 101 receives print job informa- 
tion and status requests from LAN 100, transmits the 
print data and status commands to printer 1 02 for exe- 
cution, receives status information from printer 1 02, and 
transmits status information back to LAN 100. 
[0079] Thus, NEB 101 can not only perform RPRINT- 
ER remote printer services and PSERVER print server 
functionalities, but can also offer to network members a 
wide variety of status and control features. Through 
NEB 101, network members can access verbose 
amounts of status information stored in the NEB, such 
as the number of print jobs, the number of pages per 
job, the number of pages per minute, the time per job, 
the number of total pages per day, and the number of 
jobs per day. In addition, a great deal of control informa- 
tion may be provided from the network to printer 102, 
such as, for example, exercising the printer's front panel 
functions from a networked PC. 
[0080] All network traffic enters and leaves NEB 101 
through either BNC connector 302, which interfaces 
with network controller 510 through transceiver 1 71 , or 
RJ-45 connector 301 , which interfaces directly with net- 
work controller 51 0. To eliminate the necessity for a user 
physically to position a switch, NEB 101 includes hard- 
ware and software which automatically detects which of 
the two connectors is coupled to the network. Network 
communications are transferred between the selected 
connector and the rest of the board, with network con- 
troller 510 along with NEB control logic 520 controlling 
the flow of data between the network traffic on the se- 
lected connector and microprocessor's 173 data bus. 
[0081] All software modules executed by microproc- 
essor 173 are stored in flash EPROM 174. Some low- 
level modules which are always needed, such as timer 
tick and NVRAM read, could be executed directly out of 
EPROM 1 74, but for the most part microprocessor 1 73 
does not execute software modules directly from flash 
EPROM 174, but rather selectively loads those modules 
that are needed into DRAM 175 for execution from 
DRAM. By virtue of this arrangement, it is possible to 
select the specific modules that are retrieved from flash 
EPROM 174 for execution out of DRAM 175 so as to 
permit flexible configuration of NEB 101 . 
[0082] For example, because many communication 
protocol types may be broadcast on LAN 1 00, NEB 1 01 
includes, in flash EPROM 174, software modules for 
supporting multiple protocols. NEB 1 01 monitors all net- 
work traffic on the heterogeneous network to determine 



the protocol type or types in use, and loads the protocol 
stack or stacks which correspond to the protocols it de- 
tects into DRAM 175. 

[0083] Reprogramming flash EPROM 1 74 with a new 

s image, which may include a new protocol stack, is also 
performed via DRAM 175. When a new image and a 
command to reprogram is received, such as a command 
received over the network or serial port connector 600, 
the software reprogramming module is loaded from 

10 EPROM 174 to DRAM 175. Microprocessor 173, exe- 
cuting this module from DRAM 175, confirms that the 
new firmware image is compatible with the configuration 
of NEB 101 , and reprograms EPROM 174 if compatibil- 
ity is confirmed, as described in more detail below. 

15 [0084] Microprocessor 173, executing a loaded pro- 
tocol stack out of DRAM 1 75, can send and receive net- 
work communications to and from other LAN members 
using that protocol. Print job data are received by net- 
work controller 510 and routed to microprocessor 1 73 

20 through NEB control logic 520. Microprocessor 173 
writes the print job data to shared memory SRAM 200, 
from which printer microprocessor 151 reads the data 
and operates print engine 160 in accordance therewith. 
In addition, each of microprocessors 173 and 151 can 

25 write message data to the other microprocessor in an- 
other portion of the shared memory. 
[0085] Access to the shared SRAM 200, as discussed 
above, is arbited by arbiter control logic 400 according 
to an arbitration priority technique. Arbiter control logic 

30 400 interleaves concurrent accesses of the two micro- 
processors with one another by allowing the microproc- 
essors access to the shared SRAM on a first-come first- 
serve basis, and presenting a wait state to the lower pri- 
ority processor while the higher priority processor takes 

35 its turn. In the case of an exact tie, microprocessor 1 73 
on NEB 101 is arbitrarily given priority. 
[0086] A large portion of shared SRAM 200 is config- 
ured as a ring buffer, into which NEB microprocessor 
173 writes print data and out of which printer interface 

40 microprocessor 151 reads it. As each processor writes 
or reads blocks of data, it updates respectively a "put" 
pointer or a "get" pointer, stored elsewhere in SRAM 
200, to indicate the next location that the processor 
should access. 

45 [0087] By virtue of this arrangement, the writing proc- 
essor can determine if there is available space in the 
memory in which it may write, and the reading processor 
can determine whether there is remaining data to be 
read, by comparing the put and get pointers with one 

so another. To reduce the amount of contention for shared 
memory between the two processors, NEB microproc- 
essor 173 stops writing to memory (and accordingly 
stops reading and updating the pointers) at predeter- 
mined intervals, allowing printer interface microproces- 

55 sor 151 sole access to the memory until it catches up, 
as described in more detail below. 
[0088] Serial port connector 600 is provided to allow 
NEB 101 to be debugged from an external computer. 
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Serial port connector 600 is coupled to NEB control logic 
520, which accepts serial data from receive data pin 601 
of serial port connector 600 and communicates the se- 
rial data bit-by-bit to microprocessor 1 73. Microproces- 
sor 173 configures NEB control logic 520 so that a start 
bit in the serial data activates the non-maskable inter- 
rupt of the microprocessor. Microprocessor 1 73 then as- 
sembles the data bits of the serial data into 8-bit words. 
In addition, NEB control logic 520 monitors the data bus 
of microprocessor 1 73, and passes a serial stream of 
the data presented thereon to transmit data pin 602 of 
serial port connector 600, all as described in more detail 
below. 

[Automatic Detection Of Network Hardware 
Connection] 

[0089] Network interface cards generally provide sev- 
eral different types of physical connections for connect- 
ing network cables to a LAN. NEB 1 01 , for example, pro- 
vides a BNC connector 302, to which a 1 0Base-2 coax- 
ial cable may couple, and an RJ-45 connector 301 to 
which 1 0Base-T unshielded twisted pair (UTP) wire may 
couple. Other physical connections, such as an IBM da- 
ta connector for a shielded twisted pair (STP) wire or an 
ST fiber optic connector for a fiber optic cable, are also 
possible. 

[0090] Typically, when a network interface card is con- 
nected to a LAN through one of its several connectors, 
a user who establishes or changes the connection with 
the LAN must not only insert the LAN cable in the proper 
connector, but must also physically change the position 
of a hard switch, or "jumpers", so that data is routed to 
and from the proper connector. 

[0091] Due to human error, however, it is possible for 
the user to forget to change the jumpers, or to put the 
jumpers in an improper state with respect to the connec- 
tion that has been established. In such a situation, of 
course, the card could not talk to the network at all. Iso- 
lating and correcting the problem results in an unaccept- 
able waste of time, manpower and computer resources. 
A network interface card which automatically senses 
which connector has been connected to the LAN, and 
then routes data to and from that connector, would 
greatly streamline the process for establishing and/or 
changing connections. 

[0092] The present invention provides for such auto- 
matic detection of the hardware connection by testing, 
in turn, each of the connectors for an indication of net- 
work connectivity, and thereafter selecting one of the 
connectors so that network communications can be 
transferred between the selected connector and the on 
board processor. Briefly, a network controller includes a 
first detector which detects whether the first connector 
is electrically connected to the network, and a first reg- 
ister, which the processor can read, which stores a "jab- 
ber" bit which indicates whether the second connector 
is improperly terminated. A second register, which the 



processor can also read, stores a "good- 1 ink" bit which 
indicates that the first detector has detected that the first 
connector is electrically connected to the network, and 
a control register, to which the processor can write, 
5 stores a select bit. The control register outputs the se- 
lection signal in accordance with the select bit stored 
therein. 

[0093] The microprocessor executes a software-con- 
trolled selection process by (1) writing a select bit to the 
10 control register so as to cause output of a selection sig- 
nal which selects the first connector (here, RJ-45 301 ), 

(2) reading the good-link bit from the second register, 

(3) maintaining the state of the selection bit when the 
good-link bit indicates electrical connection to the net- 
's work, (4) writing a select bit to the control register so as 

to cause output of a selection signal which selects the 
second connector (here, UTP 302) when the good-link 
bit does not indicate electrical connection to the net- 
work, (5) reading the jabber bit from the first register, (6) 

20 maintaining the state of the select bit when the jabber 
bit does not indicate improper electrical termination of 
the second connector, and (7) repeating the selection 
process when the jabber bit indicates improper electrical 
termination of the second connector. This sequence al- 

25 lows the selection process to take place long after pow- 
er-on of the board. Once a selection is made, it is main- 
tained for the entire power-on cycle of the board. 
[0094] More particularly, and referring to Figure 8, 
BNC connector 302 (through transceiver 171) and RJ- 

30 45 connector 301 are each coupled to selector 511 in 
network controller 51 0. Network traffic flows to and from 
microprocessor 173 through bus 181 via either BNC 
connector 302 or RJ-45 connector 301 , depending on 
the state of selector 51 1 . The position of selector 51 1 is 

35 determined by the output of control register 521 . 

[0095] When RJ-45 connector 301 is coupled to a 
LAN, an electric current will be present at the connector. 
Accordingly, network controller 510 includes a good-link 
detector 51 2 which monitors RJ-45 connector 301 to de- 

40 termine whether RJ-45 connector 301 is electrically con- 
nected to LAN 100. In the 83902 network controller, 
good-link detector 512 is configured as an open drain 
N-channel device. When an electrical current is detect- 
ed at RJ-45 connector 301 , the output of good-link de- 

45 tector 512 will be low and status LED 305 will be lit, in- 
dicating an electrical connection. If there is no current 
at RJ-45 connector 301 , on the other hand, the output 
of good-link detector will go high, turning off status LED 
305. The output of the good-link bit is also fed to good- 

50 link register 522 in NEB control logic 520, which allows 
microprocessor 173 to read the state of the good-link 
signal. 

[0096] A BNC connector, such as BNC connector 
302, will "jabber" unless the connector is properly termi- 
55 nated, such as, for example, when it is coupled to a LAN 
with a T-type coaxial adapter. Network controller 51 0 in- 
cludes jabber detector circuit 513, which detects wheth- 
er there is jabbering at BNC connector 302 in a manner 
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well known in the art, and writes the result of its detection 
into jabber register 514. Thus, jabber register 514 con- 
tains a bit which indicates whether BNC connector 302 
is property terminated. The jabber bit can then be read 
by software. 

[0097] Microprocessor 1 73 controls the state of selec- 
tor 511 by executing a software module stored in flash 
EPROM 1 74 in a manner that will now be described with 
reference to the flowchart of Figure 9. After NEB 101 is 
powered-up (step S900), microprocessor 173 sets se- 
lector 51 1 to the RJ-45 position by writing a zero to con- 
trol register 521 via bus 181 (step S901). The program 
reads the state of good-link register 522 (step S902), 
and, if the bit stored in good-link register 522 is low (in- 
dicating an electrical current), the program determines 
that RJ-45 connector 301 is coupled to LAN 100, and 
exits, leaving selector 511 in the RJ-45 position 
(S903-S904). 

[0098] Because there is an inherent delay in the 
switching of the N-channel device which comprises 
good-link detector 512, it is necessary to give good-link 
detector 512 ample time to detect an electrical connec- 
tion. Accordingly, if the bit stored in good-link register 
522 is high (indicating no electrical connection), the pro- 
gram will re-read good-link register 522 repeatedly, ex- 
iting and leaving selector 51 1 in the RJ-45 position if the 
bit is low for any of the reads (steps S905-S906-S902). 
If the bit stored in good-link register 522 is high after five 
hundred reads, however, the program sets selector 51 1 
to the BNC position by writing a one to control register 
521 (step S907). 

[0099] The program then reads jabber register 514 
(step S908). If the state of jabber register 51 4 is low (in- 
dicating that BNC connector 302 is properly terminated 
and a BNC connection is present), the program exits, 
leaving selector 511 in the BNC position (steps 
S909-S91 0). If the state of the jabber bit is high (indicat- 
ing that BNC connector 302 is improperly terminated 
and thus not connected to LAN 100), the program re- 
turns to S901 , resetting selector 511 to the RJ-45 posi- 
tion. The program then re-executes itself cyclically until 
either an RJ-45 or a BNC connection has been estab- 
lished. 

[0100] Thus, NEB 101 will continue to toggle between 
BNC connector 302 and RJ-45 connector 301 , checking 
after each toggle whether that particular connector is 
connected to LAN 100. By virtue of this arrangement, 
NEB 101 is able to determine, at power-up (and until a 
connection is made), whether its BNC connector 302 or 
its RJ-45 connector 301 has been connected to the net- 
work, without requiring an operatorto physically change 
a switch. Accordingly, the possibility that NEB 101 will 
attempt to communicate with LAN 100 through a con- 
nector that is not coupled to LAN 100 is eliminated. 
[0101] In the present embodiment, the selected hard- 
ware connection is maintained during the current power- 
on cycle. It is possible to implement software which, af- 
ter a selection is made, senses when the hardware con- 
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nection is no longer valid, and then repeats the selection 
process, thereby permitting connectors to be changed 
during the current power-on cycle. This allows for dy- 
namic switching form one connection to another. 

5 

[Network Protocol Sensor] 

[0102] To ensure proper operation in a multi-protocol 
system, and to guard against making improper assump- 
10 tions concerning the protocol and frame type being used 
on a network, NEB 101 utilizes autoprotocol detection 
to determine frame types used by network traffic, and to 
correlate those frame types with a particular one of sev- 
eral different protocols available to NEB 1 01 . Specif Seal- 
's ry, through use of the PRETASK module stored in flash 
EPROM 1 74, NEB microprocessor 173 is able to deter- 
mine which frame type is being used for network traffic, 
to correlate that frame type to one of several different 
protocols, and to load a protocol stack (such as iPX/SPX 
20 or TCP/IP) from flash EPROM 174 so as to carry out 
network communications using that protocol and the de- 
tected frame type. 

[0103] Figures 10 and 11(a) through 11(d) are used 
for describing this process. Figure 10 is a flow diagram 

25 showing process steps executed by NEB microproces- 
sor 1 73 in accordance with the PRETASK software mod- 
ule loaded in flash EPROM 174. PRETASK is similar to, 
though different from, the PRESCAN software module 
which is described in co-pending application EP-A- 

30 0598510, "Method And Apparatus For Adaptively De- 
termining The Format Of Data Packets Carried On A Lo- 
cal Area Network", the contents of which are incorporat- 
ed herein by reference (representative's reference 
2275230, US Serial No. 07/978,409). 

35 [0104] In step S1001, microprocessor 173 loads 
MLID (multi-link interface driver) from flash EPROM 1 74 
into DRAM 175 and begins execution of MLID. As de- 
scribed above, MLID is the lowest level of software that 
communicates to the network. MLID thus acts as the di- 

40 rect software interface to the network frame packets 
which are carried on the network wire. 
[0105] In step S1 002, microprocessor 1 73 loads LSL 
(link support layer) on top of MLID and begins executing 
LSL. LSL acts as a multiplexer between the low level 

45 MLID and various protocol stacks which may be loaded 
above it. In particular, LSL accepts registrations of any 
of the various frame types with which frame packets may 
be carried on the network. Thus, for example, in an Eth- 
ernet environment, LSL will accept registrations of 

50 802.2, 802.3, EthernetJI and Ethernet_Snap, and in a 
Token-ring environment LSL will accept registrations for 
802.5 and Token_Ring_Snap. By registering a frame 
type with LSL, a software module above LSL instructs 
LSL to provide the module with all frame packets that 

55 match the registered frame type. 

[0106] In step S1003, microprocessor 173 loads 
PRETASK on top of LSL. As mentioned above, PRE- 
TASK is responsible for identifying what frame types are 
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associated with the various protocols in which NEB 1 01 
is adapted to communicate. In step S1004, PRETASK 
registers to receive from LSL all frame types that are 
supported by MLID. Thus, in the Ethernet environment 
of the present embodiment, PRETASK registers 802.2, 
802.3, EthernetJI and Ethernet_Snap with LSL, there- 
by instructing LSL to provide PRETASK with all frame 
packets which match any of the registered frame types. 
[0107] Flow then advances to step S1005 in which 
MLID and LSL monitor the network for any traffic. Spe- 
cifically, in step S1005, the network is monitored for 
broadcast traffic meaning that the destination of the traf- 
fic is unspecified (i.e., "to anyone"). Ordinarily, broad- 
cast traffic is identified by a global specification for the 
destination MAC address, for example 12 hexadecimal 
F's in sequence. Until LAN broadcast traffic is detected, 
PRETASK does nothing. 

[0108] At this point in PRETASK's execution, the re- 
lationship of the various software modules is as depicted 
in Figure 11(a). As seen there, it is possible for multiple 
network devices, such as devices 182, 183, 184 and 
1 85, each of which runs a different protocol using a dif- 
ferent frame type, all to be connected to a single LAN 
100. In Figure 11 (a), device 182 is a Novell device run- 
ning an IPX/SPX protocol using an 802.2 frame type; 
device 183 is a UNIX network device running a TCP/IP 
protocol using an EthernetJI frame type; device 184 is 
a Macintosh device running an EtherTalk protocol using 
an Ethernet_Snap frame type; and network device 1 85 
is an unidentified frame and protocol device using an 
802.3 frame type. Of course, the combinations shown 
in Figure 11 (a) are illustrative only, and it is possible, for 
example, for a Novell IPX/SPX to use an 802.3 frame 
type or any of the other frame types. The only require- 
ment is that each protocol is associated with one and 
only one frame type. 

[0109] NEB 1 01 is also connected to LAN 1 00 and in- 
cludes LSL 187 loaded on top of MLID 186. PRETASK 
1 88 is shown as having registered each of the different 
frame types which may be broadcast on LAN 1 00. Thus, 
as shown in Figure 11 (a), PRETASK 1 88 has registered 
802.2 at 1 89, EthernetJI at 1 90, Ethernet_Snap at 1 91 , 
and 802.3 at 192. 

[0110] When LAN broadcast traffic is detected, flow 
advances to step S1006 in which LSL provides the 
frame packet to PRETASK. In step S1007, PRETASK 
decodes the frame's protocol header so as to identify 
the protocol in use by that frame packet. The offset to 
this header varies depending on the frame type the pro- 
tocol is using. The following table includes some exam- 
ples of hexadecimal values and the protocol headers 
that identify the different protocols: 



Hexadecimal Value 


Protocol Type 


0800 
0806 


IP 
ARP 



20 



(continued) 



Hexadecimal Value 


Protocol Type 


809B 
8137 


EtherTalk 
IPX/SPX 



[0111] Figure 11(b) illustrates this sequence. As seen 
in Figure 1 1 (b), network device 1 82 has issued a broad- 
cast frame packet using an 802.2 frame type. Since 
PRETASK has registered, at 189 as shown in Figure 11 
(a), 802.2 with LSL, LSL provides the frame packet to 
PRETASK. PRETASK decodes the frame's protocol 
header using the above table so as to determine the pro- 
tocol in use by that frame type. 

[0112] Reverting to Figure 10, in step S1008, PRE- 
TASK de-registers the frame type just received from 
LSL. Thus, as shown at 1 89a in Figure 1 1 (b), PRETASK 
has de-registered 802.2. 

[0113] While step S1008 shows de-registration in all 
cases, there are some cases in which it is more prefer- 
able not to de-register. Particularly, each different pro- 
tocol has associated with it a list of allowable frame 
types. Examples of allowable frame types for IPX/SPX 
and for TCP/IT are as follows: 



IPX/SPX 


TCP/IP 


EthernetJI 
Ethemet_Snap 
802.2 
802.3 


EthernetJI 
Ethemet_Snap 



[01 14] As is evident from the above list, it is possible 
for two of the frame types (EthernetJI and 
Ethernet_S nap) to be used by different protocols. It 
should also be noted that it is permissible for the same 
frame type to be used by different protocols on the same 
LAN. Thus, in a preferred mode, de-registration in step 
S1008 is not performed when the frame type received 
by PRETASK in step S1006 can be used by a protocol 
that has not already registered with LSL (see step 
S1010, below). This preferred mode allows detection 
and operation of all protocqls permissible on the LAN, 
since even later-received frame types for a protocol dif- 
ferent from those already registered can be properly de- 
tected and processed by PRETASK so as to load that 
different protocol. 

[0115] In step S1009, PRETASK loads the protocol 
stack that corresponds to the protocol decoded in step 
S1 007. In the example being used in Figure 1 1 (b), since 
an IPX/SPX protocol is decoded, PRETASK loads the 
IPX/SPX protocol stack from flash EPROM 1 74. Before 
loading, the protocol stack is initialized with the frame 
type, here 802.2, just received from LSL. 
[01 16] in step S1 01 0, the newly-loaded protocol stack 
registers itself with LSL, as shown, for example, in Fig- 
ure 11(c). As seen there, the IPX/SPX protocol stack 
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registers 802.2 with LSL. By registering, and as de- 
scribed above, IPX/SPX informs LSL to provide all 
frame packets matching the registered frame type (here, 
802.2) to the newly-loaded protocol stack. 
[01 1 7] PR ETAS K then returns to step S1 005 so as to 
continue monitoring the network for broadcast traffic. If 
LSL encounters frame packets which match the remain- 
ing frame types registered by PR ETAS K, LSL provides 
those frame types to PR ETAS K for processing in ac- 
cordance with Figure 10. Thus, as additional frame 
types are encountered, such as a frame type associated 
with a TCP/IP protocol, those frames are processed by 
PRETASK so as to load the appropriate protocol stack 
from flash EPROM 174. 

[0118] Meanwhile, as shown in Figure 11(d), since a 
protocol stack has been loaded, it now begins to operate 
on the network. Specifically, whereas PRETASK was 
completely passive and did not broadcast any network 
communications, IPX/SPX broadcasts its associated 
SAP requests. Other protocol tasks loaded by PRE- 
TASK would broadcast their associated requests. For 
example, if a TCP/IP protocol stack were loaded then 
that protocol stack would broadcast RARPs so as to ob- 
tain its address from the nearest network server. 

[Smart Flash] 

[0119] As local area networks grow more complex, it 
becomes necessary to upgrade network interface 
cards, such as NEB 1 01 , with the most current technol- 
ogies available. Thus, while NEB 101 is shipped with 
operational software, that software can be repro- 
grammed subsequently over LAN 100. For example, 
from the network administrator's PC 103, the network 
administrator can remotely alter the ROM firmware im- 
age in flash EPROM 174 by downloading new data, 
which may contain for example patch codes, manufac- 
turing test routines, entire firmware updates, and differ- 
ent language versions. 

[0120] A typical PC may be connected to more than 
one LAN. For example, as shown in Figure 12, PC 1 03 
is connected to LAN 1 00, which is an Ethernet LAN, and 
to LAN 1 93, which is a Token-ring LAN, and may in fact 
function as the network administrator's PC for both net- 
works. Each of the LANs may in turn be connected to 
several printers, each of which houses an individual 
NEB. Other reprogrammable devices might also be con- 
nected to one or both of the LANs. Thus, there are mul- 
tiple NEBs, or other devices, which the network admin- 
istrator can potentially reprogram. 
[0121] To reprogram a particular NEB, the network 
administrator from PC 103 activates a program that 
scans the network bindery to identify suitable flash tar- 
gets from all network devices connected to the network. 
Suitable flash targets include all NEB-like devices which 
have flash capabilities and include Ethernet devices and 
Token- ring devices. The network administrator selects 
one of the devices for reprog ramming and establishes 



network communication with that device. The flash 
EPROM on board then reprograms itself with the new 
image. 

[0122] Because the network administrator may be ad- 
s ministrating two or more networks, each of which has 
several reprogrammable boards connected to it, the ad- 
ministrator must be certain that the proper image is sent 
to the targeted NEB. Thus, in the case where the net- 
work administrator wishes to reprogram flash EPROM 
io 174 on NEB 101 (where the NEB is connected to an 
Ethernet LAN), he must be certain that the image he 
sends is an Ethernet image, and that it is compatible 
with other aspects of NEB 101 . 

[0123] The results of downloading an incompatible 

15 image can be devastating. For example, if the network 
administrator erroneously downloads a Token-ring im- 
age to NEB 101, and NEB 101 subsequently repro- 
grams its flash EPROM 174 with that image, then NEB 
101 will no longer be able to communicate on Ethernet 

20 LAN 1 00 at all. This means that NEB 1 01 could not even 
be reprogrammed over LAN 100; it is, quite literally, a 
"dead" board as far as the Ethernet LAN is concerned. 
Other incompatibilities, such as, for example, incompat- 
ibilities in the host interface configuration (the type of 

25 interface between the NEB and the peripheral in which 
it is housed), product configuration (the NEB's board 
type), processor configuration (the type and speed of 
the processor on board), and memory configuration (the 
size and erasability of the various on board memories), 

30 can result in problems as well. Thus, where there are 
prior generations of a product, flashing software which 
works only with newer generations will also result in a 
"dead" board. 

[01 24] To prevent such disastrous results in the case 

35 where an incompatible image is downloaded, NEB 101 
includes a software code which ensures that the down- 
loaded image is compatible before actual reprogram- 
ming occurs. More particularly, flash EPROM 174 in 
NEB 1 01 stores a current program image which includes 

40 a network information file (NIF) block which contains 
configuration information for NEB 101, and a software 
module for reprogramming flash EPROM 174. Micro- 
processor 1 73 sends and receives network communi- 
cations, and when a new program image is received 

45 over the network, microprocessor 173 downloads the 
new image into DRAM 175, confirms that the new pro- 
gram image is compatible with the configuration infor- 
mation in the NIF block, and reprograms flash EPROM 
174 only in the case where compatibility is confirmed. 

50 [0125] In greater detail, the NIF block contains per- 
manent, adapter specific configuration information, and 
is unique for each individual NEB. In a preferred embod- 
iment, the NIF block occupies 32 bytes of memory space 
in flash EPROM 413, and is divided into 4 banks of 8 

55 bytes each. As shown in Figure 13, the NIF block in- 
cludes a MAC address information bank, a board ver- 
sion and identification information bank, a component 
identification information bank and a general informa- 
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tion bank. 

[0126] The MAC address information bank, as the 
name implies, stores the board's unique MAC address. 
The board verification and identification information 
bank is subdivided into four smaller banks. Because net- 
work interface cards other than the NEB may be coupled 
to the LAN as well, a product category bank identifies 
the type of product coupled to the LAN and a board re- 
vision bank identifies the product's revision number. 
[0127] The network physical medium bank is further 
subdivided into a physical network bank, which identi- 
fies the physical medium on which the board is used 
(such as, for example, Ethernet, Token-ring or FDDI) 
while the supported connectors block identifies the 
types of physical connectors the board supports (such 
as, for example, 10baseT, 10base2 and 10base5 in the 
case of an Ethernet network, and UTP and STP in the 
case of a Token-ring network). In the host interface 
method bank, the type of interface to the peripheral that 
houses the board (such as printer 102 in the case of 
NEB 101) is identified. Examples of such interface types 
include shared RAM, small computer system interface 
(SCSI), standard parallel interface, RS-232C serial in- 
terface and Centronics parallel interface. 
[0128] The component identification information bank 
is also subdivided into several smaller banks. These 
banks identify the sizes and granularities of the ROM, 
DRAM and NVRAM on the board, as well as the erasa- 
bilty of the ROM. In addition, the network controller 
(DP83902 chip in the case of Ethernet and TI380C25 in 
the case of Token-ring) and host controller (arbited 
shared RAM, NCR53C90A SCSI controller or 
NCR53C80 SCSI controller) are identified, in the CPU 
identification bank, the type of processor and the clock 
speed are stored. Finally, the general information bank 
can store other data identifying additional configuration 
attributes of the board such as hardware revision level. 
[0129] Referring to Figure 14, a reprogramming of 
flash EPROM 174 of NEB 101 begins when the CP- 
FLASH program on the network administrator's PC 
scans the bindery (step S1401) and presents a list of 
potential flash targets to the administrator. The admin- 
istrator selects a target (step S1 402) and CP FLASH es- 
tablishes communication with the target and downloads 
the new firmware image over LAN 1 00 where it is stored 
in the NEB's DRAM 175 (step S1403). 
[0130] Once the new image is downloaded into 
DRAM 175, NEB microprocessor 173 deactivates the 
protocol stack that it is executing, since it is, at least po- 
tentially, about to be programmed, and cannot engage 
in network communications during that time (step 
S1404). Microprocessor 173 next copies the current NIF 
block from flash EPROM 174 to DRAM 175 (step 1405) 
and begins executing the software reprogramming mod- 
ule. 

[01 31] The software reprogramming module then per- 
forms image compatibility checks, referencing the infor- 
mation stored in the current image NIF block (which has 



been copied to DRAM 1 75), and comparing that infor- 
mation with the information stored in the new firmware 
image NIF block, to ensure that the new image is com- 
patible (step S1406). Because the NIF block contains a 

5 great deal of information about NEB 101, a variety of 
checks are possible to determine such compatibility. 
[0132] A first compatibility check includes a network 
media configuration checkto determine if the new image 
is of the correct network medium type (e.g., Ethernet or 

io Token -ring) by referencing the data stored in the physi- 
cal network bank of the NIF block. Similarly, a second 
compatibility check includes a host interface configura- 
tion check to determine if the new image is an image for 
interfacing with the proper host (e.g., shared RAM or 

15 SCSI) by comparing the data stored in the host interface 
method and host interface controller banks of the NIF 
block with the new image. 

[0133] A third compatibility check includes a product 
configuration check that is performed by referencing the 
20 product category and board revision banks of the NIF 
block and comparing that data with the new image to 
determine whether the new image is for the type of 
board on which the EPROM is housed. Also, a proces- 
sor configuration check can be performed by referenc- 
es ingtheCPU bank of the NIF block to determine whether 
the new image is compatible with the on board micro- 
processor, in addition, a memory configuration check 
can be performed by comparing the data stored in the 
ROM, DRAM and/or NVRAM banks of the NIF blocks 
30 with the new image to determine whether the new image 
is compatible with the board's memory. Other compati- 
bility checks, using other information stored in the NIF 
block, are also possible. 

[0134] If it is determined that the new image is incom- 
es patible, the current protocol stack is reactivated (steps 
S1407-S1408) and an error is reported to the network 
administrator's PC 103 over LAN 100, advising that an 
attempt has been made to reprogram NEB 101 with an 
incompatible image (step S1409). 
40 [0135] On the other hand, if the new image is compat- 
ible, then board-invariant portions of the NIF block of the 
new image are replaced with the corresponding portions 
of NIF block of the current image, in order to preserve 
any board specific information (such as the MAC ad- 
45 dress and board revision number) contained therein 
(steps S1 407-S1 41 0). The program then erases the cur- 
rent image from flash EPROM 174, and reprograms 
flash EPROM 174 with the new image stored in DRAM 
175, which now includes the original NIF block. 
so [0136] By virtue of this arrangement, microprocessor 
173 will never reprogram flash EPROM 174 with an in- 
compatible image, even in the case where an incompat- 
ible image was erroneously downloaded over LAN 1 00. 
Rather, in the case where a network administrator does 
55 attempt to reprogram NEB 1 01 with an incompatible im- 
age, NEB 1 01 will send a message back to the network 
administrator, advising him of the incompatibility. Ac- 
cordingly, a fail-safe measure against such human er- 
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rors is provided in an inexpensive, efficient way. 
[Arbitration Device] 

[01 37] Figures 1 5 through 1 7 are views for explaining 
arbitration of shared SRAM 200 in response to access 
requests from printer interface card 150 or from on- 
board NEB microprocessor 1 73. 
[0138] Figure 15 shows printer address/data bus (A/ 
D bus) 701 , print address latch enable (ALE) signal 702, 
printer data enable (DEN) signal 704, printer clock line 
705 and printer ready signal 706. These signals are all 
received via printer interface connector 1 70 from printer 
interface card 150. Specifically, for example, A/D bus 
701 is the A/D bus for printer microprocessor 151 
mounted on printer interface card 150. Printer ALE sig- 
nal 702 is a signal indicating when valid address infor- 
mation is carried on A/D bus 701 , and printer DEN signal 
704 is a signal indicating when valid data information is 
carried on A/D bus 701 . Printer clock 705 is the main 
clock signal for printer microprocessor 151 , and printer 
ready signal 706 is a signal which, when false, indicates 
to microprocessor 151 that a memory access is not com- 
plete and that microprocessor 151 should insert wait 
states until memory access is complete. 
[0139] Also shown in Figure 15 is NEB address/data 
bus (A/D bus) 711 , NEB ALE 71 2, read and write signals 
(WR and RD) 71 4 , N EB clock 71 5 and N EB ready signal 
716. NEB A/D bus 711 is the main address bus for mi- 
croprocessor 173, and carries address and data infor- 
mation for all components mounted on NEB 101 . NEB 
ALE signal 712 is a signal indicating when the valid ad- 
dress information is available on A/D bus 711 , read and 
write signals 714 are signals indicating when valid data 
information is available on A/D bus 711 and; in addition, 
whether to read or to write that data, NEB clock 715 is 
a main clock signal supplied by crystal oscillator 172, 
and NEB ready signal 71 6 is a signal which, when false, 
indicates to NEB microprocessor 1 73 that a memory ac- 
cess is not yet available and that microprocessor 1 73 
should insert wait states until memory access is availa- 
ble. 

[0140] Printer microprocessor 151 and NEB micro- 
processor 173 communicate, as mentioned above, 
through shared SRAM 200. Access requests for shared 
SRAM 200 are issued by microprocessor 151 and mi- 
croprocessor 173 on A/D buses 701 and 711, respec- 
tively, and are arbitrated by arbiter control logic 400, as 
described above. More particularly, and as described 
above with respect to Figure 6, arbiter control logic 400 
includes bus control logic 41 0 for controlling the bus ac- 
cesses on NEB A/D bus 711, bus control logic 420 for 
controlling bus traffic on printer A/D bus 701 , shared 
memory arbiter 430 for arbitrating between access re- 
quests on A/D bus 701 and A/D bus 711 , SRAM inter- 
face 440 for interfacing printer A/D bus 701 and NEB A/ 
D bus 711 , respectively, to address and data buses for 
SRAM 200. Each of those sections is described in more 



detail below. 

[01 41 ] Bus control logic 41 0 includes latch 71 7 which 
latches address information on NEB A/D bus 711 in re- 
sponse to NEB ALE signal 71 2 so as to provide latched 

s address information 71 9. Decoder 720 decodes latched 
address information when read or write signal 714 is ac- 
tive so as to provide a NEB request signal (NREQ sig- 
nal) 721 in the event that address information on NEB 
A/D bus 711 corresponds to address space of shared 

io SRAM 200. 

[0142] Likewise, bus control logic 420 includes latch 
722 which latches address information on printer A/D 
bus 701 when printer ALE signal 702 is high so as to 
provide latched address information 724. A decoder 725 

15 is responsive to latched address information and out- 
puts a printer request signal (PREQ) 726 when printer 
DEN signal 704 is active in the event that the latched 
address information corresponds to address space of 
shared SRAM 200. 

20 [0143] Shared memory arbiter 430 includes synchro- 
nization circuitry to synchronize the PREQ and NREQ 
access request signals to a common clock, here NEB 
clock 71 5, a delay circuit which inserts a fractional clock 
delay into one of the request signals, a hold off circuit 

25 which grants access to a first- received request signal 
and holds off access to later-received access requests, 
and a re-synchronization circuit. Specifically, both 
NREQ 721 and PREQ 726 are provided to synchroni- 
zation circuits which are both synchronized to NEB clock 

30 71 5 so as to synch ronize both access req uests to a com- 
mon clock. In the specific instance illustrated herein, 
PREQ, which is inherently synchronized to its own print- 
er clock signal 705 is synchronized to NEB clock signal 
715. Delay 729 is inserted into one of the access request 

35 signals, here into the access request signal from the 
printer, so as to produce offset request signals. The de- 
lay circuit inserts a fractional clock delay, such as a one- 
half clock delay, so as to ensure that even if both access 
requests are issued at exactly the same time, one ac- 

40 cess request will reach hold off circuit 730 before the 
other. 

[01 44] Hold off circuit 730 outputs first and second ac- 
cess grant signals PACK and NACK, in correspondence 
to the first and second access request signals. Exactly 

45 one of the first and second access grant signals is acti- 
vated in correspondence to which of the first and second 
offset request signals is received first. The other (or lat- 
er-received) offset request signal is held off until 
processing of the first-received access request signal is 

50 complete. To indicate to the h eld-off microprocessor that 
access is denied, a not-ready signal is issued. For ex- 
ample, in a case where a NEB access request is re- 
ceived after a printer access request, hold off circuit 730 
grants access to the printer and holds off access by the 

55 NEB. In that case, NEB ready signal 716 is deasserted 
indicating to microprocessor 1 73 to insert wait states un- 
til access is granted. Conversely, if a NEB access re- 
quest is received before a printer access request, hold 
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off circuit 730 grants access to the NEB and holds off 
access to the printer. In that case, hold off circuit 730 
delays printer ready signal 706 to indicate to microproc- 
essor 151 to insert wait states until access is granted. 
[0145] The PACK access grant signal for the printer 
is then fed to the re-synchronization circuit 731 in which 
the de-synchronized signal is re-synchronized with its 
own clock. The re-synchronized signal is designated as 
FPACK. The re-synchronized access grant signals, 
FPACK and NACK, are then fed to SRAM interface 440 
which provides proper interface between the microproc- 
essor that has been granted access and the shared 
SRAM 200. 

[0146] Shared memory arbiter 430 is preferably con- 
structed from D-type flip flops and standard logic circuit- 
ry. One preferred construction is shown in Figure 1 6. As 
seen there, access request signal 726 from the printer 
is fed to a synchronizing D-type flip flop 728a which is 
clocked by NEB clock signal 715 and subsequently to a 
second D-type flip flop 728b. At the same time, access 
request signal 721 from the NEB is fed to the input of a 
D-type flip flop 727a and subsequently to a second D- 
type flip flop 727b. These two flip flops 727a and 727b 
are provided so as to ensure suitable synchronization 
and delay of access request signal 721 . Trai ling-edge- 
triggered D-type flip flop 729 is provided so as to insert 
a VAt clock delay into access request signal 726 from 
the printer. Output of flip flop 729 is held low by reset 
signal 732 which is provided in the event that an access 
grant signal has already been provided to the NEB (i.e., 
the NACK signal is high). On the other hand, if access 
has not yet been granted to the NEB, then any access 
request signals from the printer are clocked through so 
as to form the PACK signal. The PACK signal is sent to 
re-synchronization flip flop 731 which is clocked by print- 
er clock 705. At the same time the PACK signal is pro- 
vided to NAND gate 734 which operates in conjunction 
with the clocked NEB access request signal. If access 
has been granted to the printer, then NAND gate 734 
ensures that access is not granted to NEB, even if re- 
quested, until PACK goes low. 

[0147] By virtue of the arrangement shown in Figure 
1 6, although the hold off circuit 730 outputs first and sec- 
ond grant signals, only exactly one of those first and sec- 
ond grant signals is activated at any one time. That is, 
if access is granted to the printer, then access is held 
off to the NEB; conversely, if access is granted to the 
NEB, access is held off to the printer. 
[0148] Returning to Figure 15, SRAM interface 440 
receives the re-synchronized printer access grant signal 
FPACK as well as NEB access grant signal NACK and, 
based on which of those signals is active, coordinates 
access between either printer microprocessor 151 or 
NEB microprocessor 1 73 to shared SRAM 200. 
[0149] More particularly, as shown in Figure 15, the 
NEB access grant signal NACK is provided to muttiplex- 
er 735 which selects either latched NEB address infor- 
mation 71 9 or latched printer address information 724 



in accordance with the NACK signal and provides the 
selected address information onto internal address bus 
736. In the case that NACK is active, then multiplexer 
735 provides all thirteen (13) bits of latched NEB ad- 

s dress information 71 9 onto internal address bus 736. On 
the other hand, if NACK is not active (i.e. , the printer has 
access), then multiplexer 735 provides twelve of the thir- 
teen bits of latched printer address information 724 onto 
internal address bus 736. The thirteenth bit, here AO, is 

10 provided by generator 747, in a manner described be- 
low. 

[01 50] Buffer 737 buffers address information from in- 
ternal address bus 736 onto SRAM address bus 740. 
Buffer 737 is activated from the output of OR gate 739. 

15 OR gate 739 accepts as one of its inputs the NEB ac- 
cess grant signal NACK; accordingly, as soon as NACK 
goes high buffer 737 buffers the address information on 
internal address bus 736 onto SRAM address bus 740. 
[0151] In accordance with whether a read or a write 

20 is requested, that is, in accordance with the status of the 
read or write signal 714, SRAM 200 either receives or 
puts data information onto its data bus 741 . That data 
information is transferred via bi-directional buffer 742 
onto internal data bus 744. Bi-directional buffer 742 is 

25 activated by the output from OR gate 745 which accepts 
as one of its inputs NEB access grant signal NACK. Ac- 
cordingly, when NACK goes high, the output of OR gate 
745 goes high which in turn allows transfer of data in- 
formation from SRAM data bus 741 to internal data bus 

30 744. Data information on internal data bus 744 is trans- 
ferred to NEB A/D bus 711 by bi-directional buffer 746 
which is activated by the NEB access grant signal 
NACK. Since the NEB access grant signal NACK de- 
rives itself ultimately from decoder 720 which is trig- 

35 gered by read or write signal 714, timing of data infor- 
mation on NEB A/D bus 711 is proper inasmuch as bus 
711 no longer expects valid address data to appear on 
it but rather now expects valid data information to ap- 
pear on it. 

40 [0152] Thus, in summary, when the NEB is granted 
access to shared SRAM 200, latched address informa- 
tion from latch 717 is buffered onto SRAM address bus 
740 via multiplexer 735 and buffer 737, and data infor- 
mation is buffered to (or from) NEB A/D bus 711 from 

45 (orto) SRAM data bus 741 via bi-directional buffers 742 
and 746. When access operations for the NEB are com- 
plete, any held off access requests from the printer are 
processed. 

[0153] In the event that printer microprocessor 151 
50 has been granted access to shared SRAM 200, then 
even though printer microprocessor 151 uses the same 
1 3-bit wide address that NEB microprocessor 1 73 uses, 
because microprocessor 151 has a data bus width 
which is different than that of SRAM 200, upper- and 
55 lower-byte buffers are required so as to resolve these 
bit-width differences. More particularly, as described 
above, printer microprocessor 151 is a 32-bit Intel 
80960KB RISC microprocessor which, through conven- 
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tion, communicates with external devices through 1 6-bit 
wide shared RAM data access. Resolution of 1 6-bit ac- 
cesses to internal 32-bit format of printer microproces- 
sor 151 is left to the printer microprocessor. However, 
resolution of 1 6-bit data accesses from microprocessor 
151 to 8-bit wide shared SRAM 200 is left to SRAM in- 
terface 440 and the above-mentioned upper byte and 
lower byte buffers. That structure is described in more 
detail below. 

[0154] More particularly, for address information 
latched in latch 722, multiplexer 735 transfers twelve of 
the thirteen bits onto internal address bus 736. The thir- 
teenth bit, here AO, is provided from generator 747. 
Generator 747 is activated by lower strobe output 750 
and upper strobe output 752, both from strobe generator 
751 . Strobe generator 751 is arranged so as to provide 
two consecutive signals, lower strobe 750 and upper 
strobe 752, in response to receipt of an FPACK access 
grant signal from shared memory arbiter 430. Lower 
strobe signal 750 is provided to generator 747 which, in 
turn, provides a binary zero bit for the thirteenth address 
bit to multiplexer 735. Multiplexer 735 selects these thir- 
teen address bits onto internal address bus 736. The 
address information on internal address bus 736 is, as 
mentioned above, latched onto SRAM address bus 740 
via buffer 737. Buffer 737 is activated by output of OR 
gate 739 which includes as its inputs upper strobe 752 
and lower strobe 750. Thus, in response to each con- 
secutive upper and lower strobe signal 750 and 752, OR 
gate 739 outputs a signal to buffer 737 which causes 
address information on internal address bus 736 to be 
transferred to SRAM address bus 740. 
[0155] Upper address strobe 752 is also provided to 
generator 747 which generates a binary one bit for the 
thirteenth address bit to multiplexer 735. Multiplexer 735 
selects those thirteen bits onto internal address bus 736. 
That modified address information is, in sequence with 
receipt of upper strobe 752 by OR gate 739, transferred 
to address bus 740 of SRAM 200. 
[0156] Handling of data information depends on 
whether a read or a write is requested by printer micro- 
processor 151 . In the case of a write, strobe generator 
751 provides lower strobe signal 750 to buffer 754 which 
buffers the lower byte of data information on printer A/ 
D bus 701 to internal data bus 744. That data informa- 
tion is buffered to SRAM data bus 741 via bi-directional 
buffer 742 which is activated by output of OR gate 745 
which, in turn, accepts as one of its inputs the printer 
access grant signal FPACK. Thus, the lower byte of data 
information on printer A/D bus 701 is transferred via 
buffer 754 onto internal data bus 744 and thence to 
SRAM data bus 741. 

[0157] The upper byte of data information on printer 
A/D bus 701 is buffered by buffer 755 which is activated 
by upper strobe signal 752 from strobe generator 751 . 
As before, that upper byte of data information is trans- 
ferred onto internal data bus 744 and thence to SRAM 
data bus 741 via bi-directional buffer 742. 



30 

[0158] When printer microprocessor 151 requests a 
read of SRAM data, lower strobe signal 750 and upper 
strobe signal 752 are delayed by respective delays 756 
and 757 and the delayed strobes control respective 

5 latches 758 and 759. Those latches latch respective 
lower and upper bytes provided from data bus 741 of 
SRAM 200, assemble the upper and lower bytes onto 
printer A/D bus 701, and provide the assembled data 
information to printer microprocessor 151 . 

10 [0159] Thus, in summary, when printer microproces- 
sor 1 51 is granted access to shared SRAM 200, address 
information latched in latch 722 is provided to the ad- 
dress bus of SRAM 200, and data information written to 
(or read from) SRAM 200 is resolved by lower and upper 

15 buffers 754 and 755 into data information for SRAM data 
bus 741 (or assembled from data information from data 
bus 741 by latches 758 and 759). When access by print- 
er microprocessor 151 is complete, any held off access 
requests from the NEB are then processed. 

20 [0160] OR gate 760 outputs a chip select signal 761 
to shared SRAM 200. Inputs to OR gate 760 are lower 
address strobe 750, upper address strobe 752 and N EB 
access grant signal NACK. Thus, in response to any of 
those signals, chip select signal 761 is issued. 

25 [0161] Figure 17 is a timing diagram showing timing 
of signals provided to arbiter control logic 400. Specifi- 
cally, on the printer side and as discussed above, arbiter 
control logic 400 is provided with printer clock 705, print- 
er ALE signal 702, printer A/D bus 701 , printer DEN sig- 

30 nal 704 and printer ready signal 706. In response to ad- 
dress information on printer A/D bus 701 which corre- 
sponds to address space in shared SRAM 200, which 
is valid and latched when printer ALE signal 702 goes 
high, and which thereafter generates a printer request 

35 signal 726 (Figure 15) when printer DEN signal 704 
goes low, hold off circuit 730 in arbiter control logic 400 
generates a printer ready signal 706 to cause printer mi- 
croprocessor 1 51 to generate wait states until access to 
SRAM 200 has been granted and valid data appears on 

40 printer A/D bus 701 , as indicated when printer DEN sig- 
nal 704 goes high. 

[0162] On the NEB side, in response to address infor- 
mation on NEB A/D bus 711 which corresponds to ad- 
dress space in SRAM 200, which is valid and latched 
45 when NEB ALE signal 712 goes low, and which there- 
after generates a NEB request signal 721 when NEB 
write signal 71 4 (not shown) goes low, a NEB ready sig- 
nal 71 6 is generated until access to SRAM 200 is grant- 
ed and valid data appears on NEB A/D bus 711 . 

so 

[Reducing Bus Contention In Shared Memory] 

[0163] As discussed above, arbiter control logic 400 
is integral to the design of NEB 1 01 , in that it allows only 
55 one of the processors to access shared SRAM 200 at a 
given point in time. This prevents simultaneous access 
to the same memory cell, thereby preventing data cor- 
ruption. However, the arbitration, by necessity, is per- 
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formed on the entire memory array, and not on individual 
memory cells. Thus, one processor must wart while the 
other accesses the memory, even if the two referenced 
addresses are different with respect to one another. This 
can lead to very slow memory access times, particularly 5 
in the case where print data is being transferred from 
the network by NEB microprocessor 1 73 to printer inter- 
face microprocessor 1 51 via shared SRAM 200. 
[0164] Figure 18 shows how available memory in 
SRAM 200 is divided in logical space. All data trans- w 
ferred from NEB 101 to printer 102, including print job 
data, commands and status requests, are written by 
NEB microprocessor 173 into printer data area 201, 
from where the data are read by printer interface micro- 
processor 151. Conversely, all data transferred from 15 
printer 102 to NEB 101 are written by printer interface 
microprocessor 151 into message data area 202, from 
where the data are read by NEB microprocessor 173. 
[0165] As is shown in Figure 1 8, printer data area 201 
is configured as a ring buffer, in which a linear memory 20 
array is addressed circularly so that addressing auto- 
matically restarts at the beginning when the end is 
reached. Such a memory structure requires two point- 
ers: a "put" pointer which marks the next address in 
which data are to be written, and a "get" pointer marking 25 
the next address from which data are to be read. The 
values of these pointers are stored in SRAM 200 itself, 
in status message area 203. The sending processor 
controls the value of the put pointer, advancing it as it 
writes new data into the ring buffer, while the receiving 30 
processor controls the value of the get pointer, advanc- 
ing it as it copies data out. 

[0166] Data are written into the ring buffer in blocks of 
256 bytes, with the put and get pointers marking where 
the next block begins. For example, in Figure 1 8, the put 35 
pointer points to block 201 1 , indicating that that block is 
the next available space in memory in which NEB mi- 
croprocessor 1 73 is to write, while the get pointer points 
to block 201 2, indicating that that block is the next space 
in memory from which printer interface microprocessor 40 
151 is to read. Before writing a block of data into mem- 
ory, NEB microprocessor 173 reads the values of the 
put and get pointers from status message area 203, and 
compares them to determine whether there is available 
room in the ring. Similarly, printer interface microproc- 45 
essor 151 reads the values of the put and get pointers 
from status message area 203 and compares them to 
determine whether there is data to be read. 
[0167] Thus, in transferring data from one processor 
to another using a ring buffer, the receiving processor 50 
follows the sending processor "around the ring", reading 
out the data that has been written. Because the receiv- 
ing processor is limited by the speed of the printer it is 
driving, however, the sending processor generally 
writes data in faster than the receiving processor can 55 
read it out, and it is likely that, in a conventional system, 
the put pointer will loop around the ring and "catch up" 
with the get pointer that is behind it. In such a case, the 



sending processor simply waits until memory space be- 
comes available in the ring. During that waiting time, in 
conventional systems the sending processor reads and 
compares the put and get pointers periodically to deter- 
mine if space has become available. Such polling by the 
sending processor slows down the receiving processor, 
since the sending processor must access the shared 
memory to read the values of the pointers, which pre- 
vents access by the printer and degrades the perform- 
ance of the entire system. 

[01 68] In N EB 1 01 , bus contention is reduced by pre- 
venting the put pointerfrom being ahead of the get point- 
er by more than a predetermined amount and then wait- 
ing until the get pointer catches up. The NEB does not 
poll shared SRAM 200 to determine when the get point- 
er catches up with the put pointer, but rather relies on 
another device, here interrupt control register 450, to 
provide notification of when the get pointer catches up. 
Specifically, it is a feature of the printer interface that the 
print data can contain a command for the printer to gen- 
erate an acknowledgement to the NEB via interrupt con- 
trol register 450. The NEB inserts this command in the 
last block of print data that it sends to the printer, and 
uses the acknowledgement from interrupt control regis- 
ter 450 as a substitute for polling. Specifically, the NEB 
sends print data to the printer by (1 ) determining wheth- 
er there is available space in shared RAM for the print 
data by reference to a counter of outstanding acknowl- 
edgements, (2) if there is available space, reading the 
get and put pointers and determining whether the put 
pointer is equal to one of plural partition indices which 
correspond to the number of partitions into which the 
ring buffer is divided, (3) writing a command requesting 
the receiving processor (the printer) to issue an ac- 
knowledgement in the case where the value of the put 
pointer is equal to one of the predetermined indices, (4) 
writing a block of print data into the shared memory at 
the location of the put pointer, and thereafter, (5) updat- 
ing the value of the put pointer. When NEB 101 writes 
a command requesting the printer to issue an acknowl- 
edgement, it updates the number of outstanding ac- 
knowledgements that it expects to receive from the 
printer by adding one to the counter of outstanding ac- 
knowledgements. When an acknowledgement is re- 
ceived from the printer, the counter of outstanding ac- 
knowledgements is reduced by one. The counter is not 
stored in shared SRAM 200, but rather is stored in 
DRAM 1 75 which is owned by NEB microprocessor 1 73 
and for which there is no problem of bus contention. Ac- 
cordingly, NEB 101 determines whether there is space 
available in the ring buffer by comparing the number of 
outstanding acknowledgements stored in the counter to 
the number of partitions into which the ring buffer is di- 
vided. If the number of outstanding acknowledgements 
is greater than or equal to the number of partitions, then 
the ring buffer is full and NEB 101 does not write any 
additional print information to the ring buffer; instead, it 
waits until an acknowledgement is received which indi- 
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cates that the printer has cleared out one partition of the 
ring buffer and that that partition is now available for new 
print information. On the other hand, if the number of 
outstanding acknowledgements is less than the number 
of partitions, then there is still available space in the ring 
buffer. 

[0169] Figure 19 shows the procedure by which the 
sending processor on NEB 101 (i.e., NEB microproces- 
sor 1 73) writes data into shared SRAM 200. The proc- 
ess begins when a print job is received from the LAN 
(step S1902). When the print job is received, NEB mi- 
croprocessor 173 determines whether there is space 
available in the ring buffer for print data. This is accom- 
plished by counting the number of outstanding acknowl- 
edgements which are expected from the printer. More 
specifically, as mentioned above, it is possible for NEB 
microprocessor 1 73 to insert commands mixed with the 
print data which cause the printer to issue an acknowl- 
edgement which is conveyed from the printer to NEB 
microprocessor 173 via interrupt control register 450. 
NEB microprocessor 173 tracks the number of out- 
standing acknowledgements, that is, the number of 
commands issued for an acknowledgement minus the 
number of acknowledgements actually received. If the 
number of outstanding acknowledgements is less than 
the number of partitions into which the ring buffer has 
been divided (here, the ring buffer has been divided into 
two partitions), then space is available in the ring buffer 
for more print data; on the other hand, if the number of 
outstanding acknowledgements is equal to or greater 
than the number of partitions into which the ring buffer 
has been divided, then no more space is available and 
N EB microprocessor 1 73 waits until acknowledgements 
have been received. 

[0170] Thus, in step S1903, NEB microprocessor 1 73 
determines whether an acknowledgement has been re- 
ceived from the printer. If an acknowledgment has been 
received, flow branches to step S1904 in which the 
number of outstanding acknowledgements is updated. 
In any event, flow then advances to step S1 905 in which 
NEB microprocessor 173 determines whether space is 
available in the ring buffer for the print data received in 
step S1902. As mentioned above, NEB microprocessor 
1 73 does not determine whether space is available by 
accessing the put and get pointers, since such accesses 
would cause needless bus contention. Instead, NEB mi- 
croprocessor 1 73 determines whether there is space 
available by comparing the number of outstanding ac- 
knowledgements to the number of partitions into which 
the ring buffer has been divided. If the number of out- 
standing acknowledgements is not less than the number 
of partitions, then no space is available in the ring buffer 
and flow returns to step S1903 until an additional ac- 
knowledgement is received. On the other hand, if the 
number of outstanding acknowledgements is less than 
the number of partitions, then space is available in the 
ring buffer and flow advances to step S1 906. 
[0171] In step S1906, the put and get pointers are 



read from shared SRAM 200 from status message area 
203. In step S1 907, if the put pointer equals a partitioned 
index, that is, if the put pointer points to the end of a 
partition in the ring buffer, such as index A and index B 

5 in Figure 18, then NEB microprocessor 173 inserts a 
command for the printer to issue an acknowledgement. 
More specifically, if the put pointer is equal to one of the 
partitioned indices, then flow branches to step S1 908 in 
which the NEB microprocessor writes its next block of 

10 print data into the memory location indicated by the put 
pointer, but also includes in the block a command for the 
receiving processor (i.e., printer microprocessor 1 51 ) to 
issue an acknowledgement. NEB microprocessor 173 
next updates the value of the put pointer (step S1909), 

is and then updates the number of outstanding acknowl- 
edgements (step S1910). Flow then advances to step 
S1 91 1 in which it is determined whether more print data 
needs to be sent to the printer. If more data needs to be 
sent, then flow returns to step S1 903 in which NEB mi- 

20 croprocessor 1 73 determines whether space is availa- 
ble in the ring buffer by reference to the number of out- 
standing acknowledgements. 

[0172] On the other hand, if in step S1907 the put 
pointer is not equal to one of the partitioned indices, then 

25 flow continues at step S1912 in which NEB microproc- 
essor 173 simply writes its next block of print data into 
the memory location indicated by the put pointer, up- 
dates the value of the put pointer (step S1 91 3) and con- 
tinues on to step S1 91 1 to determine whether more print 

30 data needs to be sent to the printer. 

[0173] The receiving processor issues acknowledge- 
ments when it reads from the shared memory the data 
block that includes that command. More particularly, 
and referring to Figure 20, the receiving processor be- 

35 gins its data retrieval by reading the values of the get 
and put pointer from the shared memory (step S2001 ). 
If there is data to retrieve (step S2002), the receiving 
processor reads the block of data from the memory lo- 
cation indicated by the get pointer (steps S2002-S2004) 

40 and updates the value of the get pointer (step S2005). 
[0174] The receiving processor then executes any 
commands that were included in the data block (step 
S2006), such as, for example, a command to issue an 
acknowledgement. The receiving processor issues this 

45 acknowledgement as an interrupt to the sending proc- 
essor, which it generates by writing a bit to interrupt con- 
trol register 450 that is part of arbiter control logic 400. 
When the sending processor receives the interrupt, it 
updates its number of outstanding acknowledgements, 

50 as described above. 

[01 75] Accordingly, when the ring buffer is partitioned 
into two partitions, the sending processor writes blocks 
to only half of the ring buffer at a time, checks if the re- 
ceiving processor has finished reading the other half, 

55 and ceases to access the shared memory at each of the 
indices until the receiving processor catches up. In al- 
ternative embodiments, the ring can be further divided 
into finer granularities in those situations where two ring 
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segments are insufficient. In those cases, as shown in 
Figures 21 (a) through 21 (c), for example, additional in- 
dices would be used. 

[0176] By virtue of this structure, the waiting of NEB 
microprocessor 1 73 will not hinder the reading of printer 
interface microprocessor 151, since NEB microproces- 
sor 173 will not be accessing the shared SRAM 200 at 
all at that time. This not only achieves a greater data 
throughput, since the printer interface microprocessor 
151 can accomplish its task more quickly, but also frees 
NEB microprocessor 1 73 from having to poll the put and 
get pointers, allowing it to perform other work not involv- 
ing shared SRAM 200. 

[Serial Port] 

[0177] Serial port connector 600, as mentioned 
above, is provided for serial communications with exter- 
nal processors, particularly a processor used in connec- 
tion with debug services for NEB 101. Specifically, via 
serial port connector 600, an external processor is able 
to retrieve debug information transmitted by NEB 101 
when NEB 101 is set to a debug state. That information 
can include, for example, status of internal NEB regis- 
ters, status of network broadcasts and traffic on network 
interface 301 (or 302, whichever is enabled), status of 
print information as well as print information being writ- 
ten to shared SRAM 200 and the like. 
[0178] Because serial port connector 600 is used in 
connection with debug services, it is imperative that se- 
rial communications over that port are responded to by 
NEB microprocessor 173, regardless of the interrupta- 
bility of NEB microprocessor 173. For example, when 
reducing bus contention by waiting to write new print da- 
ta into SRAM 200 until printer 102 issues an acknowl- 
edgement, as described above, it is possible for the 
printer erroneously to fail to issue such an acknowledg- 
ment. In those cases, the NEB microprocessor will loop 
continuously until an acknowledgement is received. Or- 
dinarily, a processor in such a state is "locked-up" mean- 
ing that it does not respond to any interrupts; in this 
locked-up state it is ordinarily necessary to cycle power 
to the board. However, because this erroneous opera- 
tion is precisely the kind of operation for which debug 
information is desired over serial port connector 600, it 
is imperative that NEB microprocessor 173 be able to 
respond to such serial communications. 
[0179] The arrangement illustrated in the accompa- 
nying figures describes a serial port construction in 
which signals on a receive channel are transmitted to 
the non-maskable interrupt (NMI) pin of NEB microproc- 
essor 1 73. A non-maskable interrupt feature is available 
on most modern-day processors, such as the Intel 
80X86 line of processors, and it provides a means for 
interrupting the processor regardless of its current com- 
puting state. That is, when the NMI pin is activated, the 
processor must respond to the interrupt regardless of 
other operations that are currently underway. 
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[0180] More particularly, as shown in Figure 22, a se- 
rial port construction according to the invention includes 
NEB microprocessor 173 which includes a non-maska- 
ble interrupt (NMI) pin 1 731 and which is connected via 

5 bus 181 to NEB control logic 520, as described above. 
NEB control logic 520 includes address decode logic 
523 which decodes address signals on bus 181 and 
which provides access to internal registers in NEB con- 
trol logic 520. Particularly, three registers are concerned 

10 here: transmit register 524, receive register 525, and 
NMI enable register 526. 

[0181] Transmit register 524 includes a transmit bit 
which is connected to transmit pin 602 of the serial port. 
Specifically, the transmit bit is writable by NEB micro- 
's processor 1 73 via bus 1 81 and address decode logic 
523, and in accordance with a binary 1 or 0 state of that 
transmit bit a corresponding +5 or 0 volt voltage level 
appears at transmit terminal 602. 
[0182] Receive register 525 includes a receive bit 
20 which is connected to receive pin 601 of the software 
serial port. More specifically, in accordance with a volt- 
age level which appears at receive terminal 601 , the re- 
ceive bit is set to a binary 0 or 1 , and the receive bit may 
be read by microprocessor 1 73 via bus 1 81 and address 
25 decode logic 523. 

[0183] NMI enable register 526 is a switch controlla- 
ble by microprocessor 173 and which is connected be- 
tween receive terminal 601 and NMI pin 1731. Under 
control of microprocessor 173 and via bus 181 and ad- 
30 dress decode logic 523, NMI enable register 526 is 
switchable between an enable state in which signals ap- 
pearing at receive terminal 601 are connected to NMI 
pin 1 731 , and a disable state in which signals appearing 
at receive terminal 601 are blocked. 
35 [0184] Transmit register 524, receive register 525, 
and NMI register 526 can physically be constructed from 
a single register, but more typically each are provided 
in a separately addressable register, as shown in Figure 
22. 

40 [0185] Figure 23(a) shows serial port processing in a 
serial receive mode. The process steps illustrated in Fig- 
ure 23(a) are executed by NEB microprocessor 173 in 
accordance with software instructions stored in DRAM 
175. 

45 [0186] In step S2301, microprocessor 173 enables 
NMI enable register 526 so as to permit transmission of 
signals appearing at receive terminal 601 directly to NMI 
pin 1 731 . Then in step S2302, microprocessor 1 73 mon- 
itors its NMI pin 1 731 for the appearance of an NMI sig- 

50 nal. If no non-maskable interrupt has been received, mi- 
croprocessor 173 continues with ongoing processing 
(step S2303), such as continuing with networked print- 
ing operations between the computerized LAN 1 00 and 
the printer. 

55 [0187] On the other hand, when an NMI signal is re- 
ceived at NMI pin 1 731 , flow advances to step S2304 in 
which microprocessor 1 73 interrupts on-going process- 
es. As seen in Figure 23(b), because NMI enable reg- 
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ister has been enabled, an NMI signal will be received 
in correspondence to a start bit at receive terminal 601 . 
Figure 23(b) illustrates timing of signals in a serial re- 
ceive mode. Thus, as seen in Figure 23(b), when a volt- 
age level 610 corresponding to a start bit appears at re- 
ceive terminal 601 , because of the enable state of NMI 
enable register 526, that start bit is transmitted to NMI 
pin 1731. At the same time, because of voltage level 
61 0 associated with the start bit, the receive bit in re- 
ceive register 525 switches to a binary 1 . 
[0188] Reverting to Figure 23(a), after microproces- 
sor 1 73 interrupts on-going processes (step S2304), the 
microprocessor begins execution of an NMI interrupt 
handling procedure which, in step S2305, disables NMI 
enable register 526 so as to block transmission of other 
signals from receive terminal 601 to NMI pin 1731 . The 
interrupt handling procedure then waits for a serial 
transmission period so as to allow the first data bit to 
appear at receive terminal 601 . In situations where se- 
rial transmission is conducted at 19.2 KHz, the prede- 
termined serial transmission period is 1/19.2 KHz or 52 
US. After the predetermined serial transmission period 
is over, flow advances to step S2307 in which the re- 
ceived bit in receive register 525 is read. This is shown 
in Figure 23(b) in which, for illustrative purposes, the first 
data bit is a binary 1 corresponding to a high voltage 
level at receive terminal 601. The received bit is re- 
trieved from receive register 525 and steps S2306 and 
S2307 are repeated (step S2308) until eight data bits 
have been received. Any stop bits (such as 61 1 in Figure 
23(b)) that are transmitted are simply ignored. 
[0189] When eight data bits have been received, flow 
then advances to step S2309 in which the interrupt han- 
dling procedure stores an 8-bit byte of data which has 
been received at the receive terminal 601. In step 
S2310, microprocessor 173 enables the NMI enable 
register 526 so as to be prepared for receipt of a next 
serial transmission. The serial communication cycle for 
receiving one byte of serial data is then complete. 
[0190] In step S2311 , microprocessor 1 73 determines 
whether the 8-bit byte stored in step S2309 requests an 
asynchronous break-in to ongoing software tasks. More 
specifically, once the NMI interrupt handling procedure 
described above has terminated, flow ordinarily returns 
to ongoing processes such as CPSOCKET and the like, 
all under control of the MONITOR. One benefit of an 
NMI-driven serial port, however, is the ability to break 
into a running program in the midst of a problem. For 
example, in situations where the NEB has crashed due 
to unexpected software problems, the state of the NEB 
is often unknown. It might be in a very tight microproc- 
essor loop that has no debug messages being transmit- 
ted. Resetting the NEB, which is often the only way to 
breakthe microprocessor loop, will lose the current state 
and will provide no information as to the cause of the 
crash. In such a situation, the ability to break in via the 
NMI-driven serial port and examine the system is ex- 
tremely valuable. 
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[0191] Accordingly, step S2311 determines whether 
the byte received on the serial port connector requests 
asynchronous break-in. For example, by previously-ar- 
ranged convention, it might be determined that trans- 
5 mission of an exclamation point ("!") signifies a request 
for asynchronous break-in. In those instances, micro- 
processor 173 continues to suspend ongoing process- 
es, and enters an interactive debugger. The interactive 
debugger is a ROM-resident program that allows a user 
io to view or to change memory addresses, CPU registers 
and I/O ports. Additionally, the interactive debugger al- 
lows two set break points in the code and has the ability 
to start execution from any such break point. This is all 
accomplished across serial port connector 600. 
15 [0192] Thus, asynchronous break-in permits a trou- 
ble-shooter to analyze the current state of NEB when a 
problem has been encountered. Since the start bit on a 
serial communication causes an NMI signal to be gen- 
erated, asynchronous break-in allows to begin an inter- 
ne active debug session in which even a tightly-bound mi- 
croprocessor loop may be interrupted so as to permit 
analysis of the system state. 

[0193] On the other hand, if the 8-bit byte stored in 
step S2309 does not request asynchronous break-in, 

25 then microprocessor 173 simply stores the received 
byte and returns to step S2303 in which it resumes ex- 
ecution of ongoing processes that had been suspended 
in step S2304. Typically, other software modules active 
on microprocessor 173, such as CPSOCKET, monitor 

30 the data buffer into which the 8-bit byte has been stored. 
For example, by a previously-arranged convention, it 
might be determined that transmission of the character 
sequence "DNLD" signifies a request for download serv- 
ices in which a new software module or modules are 

35 downloaded over the serial port connector 600. In such 
an instance, CPSOCKET might be arranged so as to 
echo each of the "DNLD" characters as they are re- 
ceived and thereafter to enter a download mode. 
[0194] Figure 24(a) shows flow processing in the 

40 transmit mode of the software serial port, and Figure 24 
(b) shows signals appearing at transmit terminal 602 in 
connection with transmit bits written into transmit regis- 
ter 524. 

[01 95] In step S2401 , microprocessor 1 73 writes a bi- 
45 nary 1 start bit to the transmit bit in transmit register 524. 
The transmit bit, since it is connected to transmit termi- 
nal 602, causes a +5 voltage level to appear at transmit 
terminal 602. 

[0196] Flow then advances to step S2402 in which 
50 NEB microprocessor 173 waits a predetermined serial 
transmission period which, at a serial rate of 19.2 KHz 
corresponds to 1/1 9.2 = 52 u.s (one inter-bit time). After 
waiting the required period, microprocessor 1 73 writes 
the first bit in the transmitted word to the transmit bit in 
55 transmit register 524 (step S2403). Until all eight bits of 
the transmitted word have been written (step S2404), 
microprocessor 1 73 repeats steps S2402 and S2403 in 
which it waits for the serial transmission period and 
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writes a next data bit to the transmit bit in transmit reg- 
ister 524. After all eight bits have been written, flow ad- 
vances to step S2405 which, after waiting for the inter- 
bit transmission period, writes a stop bit to register 524, 
and then to step S2406 at which point serial transmis- s 
si on is complete. 

[01 97] The invention has been described with respect 
to a particular illustrative embodiment. It is to be under- 
stood that the invention is not limited to the above de- 
scribed embodiment and that various changes and 10 
modifications may be made by those of ordinary skill in 
the art without departing from the scope of the invention. 



Claims is 

1 . A method of determining which of a plurality of pro- 
tocols is used on a network, comprising the steps of: 

executing a link support layer module (t 87) so 20 
as to monitor network communications for 
broadcast frame packets (S1002), said link 
support layer modute (187) being adapted to 
accept registrations for any one of a plurality of 
frame types; 25 
registering each of the plurality of frame types 
with said link support layer module (S1004); 
receiving from said link support layer module 
(1 87) a frame packet which matches a first one 
of the frame types; and 30 
decoding header information in the received 
frame packet so as to determine which protocol 
is used by the frame packet (S1 007), 
the method being characterised by the steps 
of: 35 

de- registering the first frame type from said 
link support layer module (S1008), said 
step of de-registering not being performed 
in the case where the first frame type is an *o 
allowable frame type for a protocol stack 
not already registered with said link sup- 
port layer module (187); 
initializing a first protocol stack corre- 
sponding to the determined protocol by us- 45 
ing the first frame type; 
loading the first protocol stack (S1009); 
and 

registering the first protocol stack with said 
link support layer module (S1010) so that so 
the first protocol stack receives future 
frame packets which match the first frame 
type. 

2. A method according to claim 1 , further comprising ss 
the step of executing the first protocol stack so as 

to broadcast network communications. 



3. A method according to claim 1 , further comprising 
the steps of: 

receiving from said link support layer module a 
frame packet which matches a second one of 
the frame types; 

decoding header information in the received 
frame packet so as to determine which protocol 
is used by the frame packet; 
de-registering the second frame type from said 
link support layer module (S1008); 
initializing a second protocol stack correspond- 
ing to the determined protocol by using the sec- 
ond frame type; 

loading the second protocol stack (S1 009); and 
registering the second protocol stack with said 
link support layer module (S1010) so that the 
second protocol stack receives future frame 
packets which match the second frame type. 

4. A method according to claim 3, further comprising 
the steps of checking the first frame type against 
the second frame type and signalling an error in the 
case where said decoding step indicates that de- 
coded header information in a second- received 
frame packet corresponds to the first protocol stack. 

5. A networkable device in which each of a plurality of 
different protocol stacks communicate on a network 
(1 00) via a common link support layer module (1 87), 
comprising: 

a memory (1 74) for storing process steps, the 
process steps including process steps compris- 
ing said link support layer module (187) and 
process steps comprising said plural different 
protocol stacks; and 

a processor (173) for executing the process 
steps stored in said memory, 

wherein the process steps further include 
process steps to register each of said plural differ- 
ent protocol stacks with said link support layer mod- 
ule by: 

monitoring using said link support layer module 
network communications for broadcast frame 
packets, said link support layer module (187) 
being adapted to accept registrations for any 
one of plural frame types; 
registering each of the plural frame types with 
said link support layer module (187); 
receiving from said link support layer module 
(187) a frame packet which matches a first one 
of the frame types; and 

decoding header information in the received 
frame packet so as to determine which protocol 
is used by the frame packet, 
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the device being characterised by the proces- 
sor executing the process steps of: 

de-registering the first frame type from said 
link support layer module (187), said step s 
of de-registering not being performed in a 
case where the first frame type is an allow- 
able frame type for a protocol stack not al- 
ready registered with said link support lay- 
er module (187); 10 
initializing a first protocol stack corre- 
sponding to the determined protocol by us- 
ing the first frame type; 
loading the first protocol stack; and 
registering the first protocol stack with said is 
link support layer module so that the first 
protocol stack receives future frame pack- 
ets which match the first frame type. 

6. A device according to claim 5, further comprising 20 
process steps to execute the first protocol stack so 

as to broadcast network communications. 

7. A device according to claim 5, wherein the process 
steps further comprise: 25 

receiving from said link support layer module 
(187) a frame packet which matches a second 
one of the frame types; 

decoding header information in the received 30 
frame packet so as to determine which protocol 
is used by the frame packet; 
de- registering the second frame type from said 
link support layer module; 

initializing a second protocol stack correspond- 35 
ing to the determined protocol by using the sec- 
ond frame type; 

loading the second protocol stack; and 
registering the second protocol stack with said 
link support layer module (1 87) so that the sec- 40 
ond protocol stack receives future frame pack- 
ets which match the second frame type. 

8. A device according to claim 7, wherein the process 
steps further comprise checking the first frame type 45 
against the second frame type and signalling an er- 
ror in a case where said step to decode indicates 
that decoded header information in a second-re- 
ceived frame packet corresponds to the first proto- 
col stack. so 

9. Computer executable process steps for determin- 
ing which of a plurality of different protocols is used 
on a network, said process steps comprising: 

55 

an executing step (S1002) to execute a link 
support layer module (187) so as to monitor 
network communications for broadcast frame 



packets, said link support layer module (187) 
being adapted to accept registrations for any 
one of plural frame types; 
a registering step (S1004) to register each of 
the plural frame types with said link support lay- 
er module (187); 

a receiving step to receive from said link sup- 
port layer module (187) a frame packet which 
matches a first one of the frame types; and 
a decoding step (S1007) to decode header in- 
formation in the received frame packet so as to 
determine which protocol is used by the frame 
packet, 

the process steps being characterized by: 

a de-registering step (S1008) to de-regis- 
ter the first frame type from said link sup- 
port layer module (187), said de-register- 
ing step not being performed in the case 
where the first frame type is an allowable 
frame type for a protocol stack not already 
registered with said link support layer mod- 
ule (187); 

an initializing step to initialize a first proto- 
col stack corresponding to the determined 
protocol by using the first frame type; 
a loading step (S1 009) to load the first pro- 
tocol stack; and 

a registering step (S1010) to register the 
first protocol stack with said link support 
layer module (1 87) so that the first protocol 
stack receives future frame packets which 
match the first frame type. 

10. Computer executable process steps according to 
claim 9, further comprising an executing step to ex- 
ecute the first protocol stack so as to broadcast net- 
work communications. 

11. Computer executable process steps according to 
claim 9, further comprising: 

a receiving step to receive from said link sup- 
port layer module (187) a frame packet which 
matches a second one of the frame types; 
a decoding step to decode header information 
in the received frame packet so as to determine 
which protocol is used by the frame packet; 
a de-registering step (S1 008) to de-register the 
second frame type from said link support layer 
module; 

an initializing step to initialize a second protocol 
stack corresponding to the determined protocol 
by using the second frame type; 
a loading step (S1 009) to load the second pro- 
tocol stack; and 

a registering step (S101 0) to register the sec- 
ond protocol stack with said link support layer 
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module (187) so that the second protocol stack 
receives future frame packets which match the 
second frame type. 

12. Computer executable process steps according to 5 
claim 11, further comprising a checking step to 
check the first frame type against the second frame 
type and signal an error in a case where said de- 
coding step indicates that decoded header informa- 
tion in a second-received frame packet corre- io 
sponds to the first protocol stack. 

13. A computer software product storing computer ex- 
ecutable process steps according to any one of 
claims 9 to 12. is 



Patentanspruche 

1 . Verfahren zur Bestimmung welches aus einer Viel- 
zahl von Protokollen auf einem Netzwerk verwen- 
det wird, mit den Schritten: 

Ausfuhren eines Verbindungsunterstutzungs- 
schichtmoduls (187), so dass Netzwerkkom- 
munikationen zur Ausstrahlung von Daten- 
ubertragungsblockpaketen (S1002) uberwacht 
werden, wobei das Verbindungsunterstut- 
zungsschichtmodul (1 87) zur Akzeptierung von 
Registrierungen fur beliebige aus einer Vielzahl 
von Datenubertragungsblocktypen angepasst 
ist; 

Registrieren jedes der Vielzahl von Datenuber- 
tragungsblocktypen mit dem Verbindungsun- 
terstutzungsschichtmodul (S1004); 
Empfangen eines Datenubertragungsblockpa- 
ketes von dem Verbindungsunterstiitzungs- 
schichtmodul (187), das mit einem ersten der 
Datenubertragungsblocktypen ubereinstimmt; 
und 

Dekodieren von Kopfinformationen bei dem 
empfangenen Datenubertragungsblockpaket, 
so dass bestimmt wird, welches Protokoll durch 
das Datenubertragungsblockpaket (S1007) 
verwendet wird, 



das Verfahren ist dabei gekennzeichnet durch die 

Schritte: 

Deregistrieren des ersten Datenubertragungs- 
blocktyps von dem Verbindungsunterstut- 
zungsschichtmodul (S1008), wobei derDeregi- 
strierungsschritt nicht durchgefuhrt wird, wenn 
der erste Datenubertragungsblocktyp ein er- 
laubter Datenubertragungsblocktyp fur einen 
nicht bereits mit dem Verbindungsunterstiit- 
zungsschichtmodul (187) registrierten Proto- 
kolistapel ist; 



Initialisieren eines ersten Protokollstapels ent- 
sprechend dem bestimmten Protokoll unter 
Verwendung des ersten Datenubertragungs- 
blocktyps; 

Laden des ersten Protokollstapels (S1009); 
und 

Registrieren des ersten Protokollstapels mit 
dem Verbindungsunterstutzungsschichtmodul 
(S1010), so dass der erste Protokollstapel zu- 
kunftige Dateniibertragungsblockpakete emp- 
fangt, welche mit dem ersten Datenubertra- 
gungsblocktyp ubereinstimmen. 

2. Verfahren nach Anspruch 1 , ferner mit dem Schritt 
Ausfuhren des ersten Protokollstapels, so dass 
Netzwerkkommunikationen ausgestrahlt werden. 

3. Verfahren nach Anspruch 1, ferner mit den Schrit- 
ten: 

Empfangen eines Datenubertragungsblockpa- 
kets von dem Ve rbin dungs unterstutzun gs- 
schichtmodul, das mit einem zweiten der Da- 
tenubertragungsblocktypen ubereinstimmt; 
Dekodieren von Kopfinformationen bei dem 
empfangenen Datenubertragungsblockpaket, 
so dass bestimmt wird, welches Protokoll durch 
das Datenubertragungsblockpaket verwendet 
wird; 

Deregistrieren des zweiten Datenubertra- 
gungsblocktyps von dem Verbindungsunter- 
stutzungsschichtmodul (S1008); 
Initialisieren eines zweiten Protokollstapels 
entsprechend dem bestimmten Protokoll unter 
Verwendung des zweiten Datenubertragungs- 
biocktyps; 

Laden des zweiten Protokollstapels (S1009); 
und 

Registrieren des zweiten Protokollstapels mit 
dem Verbindungsunterstutzungsschichtmodul 
(S1 01 0), so dass der zweite Protokollstapel zu- 
kunftige Dateniibertragungsblockpakete emp- 
fangt, die mit dem zweiten Datenubertragungs- 
blocktyp ubereinstimmen. 

4. Verfahren nach Anspruch 3, ferner mit den Schrit- 
ten Uberprufen des ersten Datenubertragungs- 
blocktyps gegeniiber dem zweiten Datenubertra- 
gungsblocktyp und Signaiisieren eines Fehlers, 
wenn der Dekodierschritt angibt, dass die dekodier- 
ten Kopfinformationen bei einem als zweites emp- 
fangenen Datenubertragungsblockpaket dem er- 
sten Protokollstapel entsprechen. 



55 5. Netzwerkfahige Vorrichtung, bei der jeder aus einer 
Vielzahl von verschiedenen Protokollstapel auf ei- 
nem Netzwerk (1 00) iiber ein gemeinsames Verbin- 
dungsunterstutzungsschichtmodul (187) kommuni- 
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zieren, mit: 

einem Speicher (174) zum Speichern von Ab- 
laufschritten, die Ablaufschritte beinhalten da- 
bei Ablaufschritte mit dem Verbindungsunter- 5 
stutzungsschichtmodul (1 87) und Ablaufschrit- 
te mit den vielen verschiedenen Protokollsta- 
peln; und 

einer Verarbeitungseinrichtung (1 73) zum Aus- 
fuhren der in dem Speicher gespeicherten Ab- 10 
laufschritte, 

wobei die Ablaufschritte ferner Ablaufschritte 
zum Registrieren jedes der vielen verschiedenen 
Protokollstapel mit dem Verbindungsunterstut- *5 
zungsschichtmodul beinhatten, dies erfolgt durch: 

Uberwachen von Netzwerkkommunikationen 
zum Ausstrahlen von Datenubertragungs- 
blockpaketen unter Verwendung des 20 
Verbindungsunterstutzungsschichtmoduls, 
wobei das Verbindungsunterstiitzungsschicht- 
modul (1 87) zum Akzeptieren von Registrierun- 
gen fur eine der vielen Datenubertragungs- 
blocktypen angepasst ist; 25 
Registrieren jedes der vielen Datenubertra- 
gungsblocktypen mit dem Verbindungsunter- 
stutzungsschichtmodul (187); 
Empfangen eines Datenubertragungsblockpa- 
kets von dem Verbindungsunterstiitzungs- so 
schichtmodul (187), das mit einem ersten der 
Datenubertragungsblocktypen ubereinstimmt; 
und 

Dekodieren von Kopfinformationen bei dem 
empfangenen Datenubertragungsblockpaket, 35 
so dass bestimmt wird, welches Protokoll durch 
das Datenubertragungsblockpaket verwendet 
wird, 

die Vorrichtung ist dabei dadurch gekenn- 
zeichnet, dass die Verarbeitungseinrichtung 40 
die folgenden Schritte ausfuhrt: 

Deregistrieren des ersten Datenubertra- 
gungsblocktyps von dem Verbindungsun- 
terstutzungsschichtmodul (1 87), wobei der 45 
Schritt der Deregistrierung nicht durchge- 
fuhrt wird, wenn der erste Datenubertra- 
gungsblocktyp ein erlaubter Datenubertra- 
gungsblocktyp fur einen nicht bereits mit 
dem Verbindungsunterstutzungsschicht- so 
modul (187) registrierten Protokollstapel 
ist; 

Initialisieren eines ersten Protokollstapels 
entsprechend dem bestimmten Protokoll 
unter Verwendung des ersten Datenuber- 55 
tragungsblocktyps; 

Laden des ersten Protokollstapels; und 
Registrieren des ersten Protokollstapels 



mit dem Verbindungsuntersttitzungs- 
schichtmodul, so dass der erste Protokoll- 
stapel zukunftige Datenubertragungs- 
blockpakete empfangt, die mit dem ersten 
Datenubertragungsblocktyp ubereinstim- 
men. 

6. Vorrichtung nach Anspruch 5, femer mit Ablauf- 
schritten zum Ausfiihren des ersten Protokollsta- 
pels, so dass Netzwerkkommunikationen ausge- 
strahlt werden. 

7. Vorrichtung nach Anspruch 5, wobei die Ablauf- 
schritte ferner umfassen: 

Empfangen eines Datenubertragungsblockpa- 
kets von dem ersten Verbindungsunterstiit- 
zungsschichtmodul (187), das mit einem zwei- 
ten der Datenubertragungsblocktypen uberein- 
stimmt; 

Dekodieren von Kopfinformationen bei dem 
empfangenen Datenubertragungsblockpaket, 
so dass bestimmt wird, welches Protokoll durch 
das Datenubertragungsblockpaket verwendet 
wird; 

Deregistrieren des zweiten Datenubertra- 

gungsblocktyps von dem Verbindungsunter- 

stutzungsschichtmodul; 

Initialisieren eines zweiten Protokollstapels 

entsprechend dem bestimmten Protokoll unter 

Verwendung des zweiten Datenubertragungs- 

blocktyps; 

Laden des zweiten Protokollstapels; und 
Registrieren des zweiten Protokollstapels mit 
dem Verbindungsunterstutzungsschichtmodul 
(187), so dass der zweite Protokollstapel zu- 
kunftige Datenubertragungsblockpakete emp- 
fangt, die mit dem zweiten Datenubertragungs- 
blocktyp ubereinstimmen. 

8. Vorrichtung nach Anspruch 7, wobei die Ablauf- 
schritte ferner umfassen: 

Uberprufen des ersten Datenubertragungs- 
blocktyps gegenuber dem zweiten Datenuber- 
tragungsblocktyp und Signalisieren eines Feh- 
lers, wenn der Dekodierschritt angibt, dass de- 
kodierte Kopfinformationen bei einem als zwei- 
tes empfangenen Datenubertragungsblockpa- 
ket dem ersten Protokollstapel entsprechen. 

9. Auf einem Computer ausfiihrbare Ablaufschritte 
zum Bestimmen welches aus einer Vielzahl von 
verschiedenen Protokollen auf einem Netzwerk 
verwendet wird, dabei umfassen die Ablaufschritte: 

einen Ausfuhrungsschritt (S1 002) zum Ausfuh- 
ren eines Verbindungsunterstutzungsschicht- 
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10. Auf einem Computer ausfuhrbare Ablaufschritte 
gemaB Anspruch 9, ferner mit einem Ausfuhrungs- 
schritt zum Ausfuhren des ersten Protokollstapel, 
so dass Netzwerkkommunikationen ausgestrahlt 
werden. 

11. Auf einem Computer ausfuhrbare Ablaufschritte 
nach Anspruch 9, femer mit: 



einem Empfangsschritt zum Empfangen eines 
Datenubertragungsblockpaketes von dem 
Verbindungsunterstutzungsschichtmodul 
(1 87), das mit einem zweiten der Datenubertra- 
gungsblocktypen ubereinstimmt; 
einem Dekodierschritt zum Dekodieren von 
Kopfinformationen bei dem empfangenen Da- 
tenubertragungsblockpaket, so dass bestimmt 
wird, welches Protokoll durch das Datenuber- 
tragungsblockpaket verwendet wird; 
einen Deregistrierungsschritt (S1008) zum De- 
registrieren des zweiten Datenubertragungs- 
blocktyps von dem Verbindungsunterstut- 
zungsschichtmodul; 

einem Initialisierungsschritt zum Initialisieren 
eines zweiten Protokollstapels entsprechend 
dem bestimmten Protokoll unter Verwendung 
des zweiten Datenubertragungsblocktyps; 
einem Ladeschritt (S1009) zum Laden des 
zweiten Protokollstapels; und 
einem Registrierungsschritt(S1010) zum Regi- 
strieren des zweiten Protokollstapels mit dem 
Verbindungsunterstutzungsschichtmodul 
(187), so dass der zweite Protokollstapel zu- 
kunftige Dateniibertragungsblockpakete emp- 
fangt, die mit dem zweiten Datenubertragungs- 
blocktyp ubereinstimmen. 

12. Auf einen Computer ausfuhrbare Ausfuhrungs- 
schritte nach Anspruch 11 , ferner mit einem Uber- 
prufungsschritt zum Uberprufen des ersten Daten- 
ubertragungsblocktyps gegeniiber dem zweiten 
Datenubertragungsblocktyp und Signalisieren ei- 
nes Fehlers, wenn der Dekodierschritt angibt, dass 
dekodierte Kopfinformationen bei einem als zwei- 
tes empfangenen Datenubertragungsblockpaket 
dem ersten Protokollstapel entsprechen. 

13. Computersoftwareprodukt, das auf einem Compu- 
ter ausfuhrbare Ablaufschritte gemaB einem der 
Anspruche 9 bis 12 speichert. 



Revendlcations 

1. Procede pour determiner celui de plusieurs proto- 
coles qui est utilise sur un reseau, comprenant les 
etapes qui consistent : 

a executer un module (1 87) de couche de sup- 
port de liaison afin de contrdler des communi- 
cations de reseau pour la diffusion de paquets 
de trames (S1002), ledit module (187) de cou- 
che de support de liaison etant concu pour ac- 
cepter des enregistrements pour I'un quelcon- 
que d'une plural ite de types de trames ; 
I'enregistrement de chacun de la pluralite de ty- 
pes de trames avec ledit module de couche de 



moduls (1 87), so dass Netzwerkkommunikatio- 
nen zum Ausstrahlen von Datenubertragungs- 
blockpaketen uberwacht werden, wobei das 
Verbindungsunterstutzungsschichtmodul 
(1 87) zum Akzeptieren von Registrierungen fur s 
beliebige der vielen Dateniibertragungsblock- 
typen angepasst ist; 

einen Registrierungsschritt (S1004) zum Regi- 
strieren jedes der vielen Datenubertragungs- 
blocktyp en mit dem Verbindungsunterstiit- io 
zungsschichtmodul (187); 
einem Empfangsschritt zum Empfangen eines 
Datenubertragungsblockpakets von dem 
Verbindungsunterstutzungsschichtmodul 
(187), das mit einem ersten der Dateniibertra- 15 
gungsblocktypen ubereinstimmt; und 
einem Dekodierschritt (S1007) zum Dekodie- 
ren von Kopfinformationen bei dem empfange- 
nen Datenubertragungsblockpaket, so dass 
bestimmt wird, welches Protokoll durch das Da- 20 
tenubertragungsblockpaket verwendet wird, 
die Ablaufschritte sind dabei gekennzeichnet 
durch: 

einen Deregistrierungsschritt (S1 008) zum 2s 
Deregistrieren des ersten Datenubertra- 
gungsblocktyps von dem Verbindungsun- 
terstutzungsschichtmodul (1 87), wobei der 
Deregistrierungsschritt nicht durchgefuhrt 
wird, wenn der erste Dateniibertragungs- 30 
blocktyp ein erlaubter Datenubertragungs- 
blocktyp fur einen nicht bereits mit dem 
Verbindungsunterstutzungsschichtmodul 
(187) registrierten Protokollstapel ist; 
einen Initialisierungsschritt zum Initialisie- 35 
ren eines ersten Protokollstapels entspre- 
chend dem bestimmten Protokoll durch 
Verwenden des ersten Datenubertra- 
gungsblocktyps; 

einen Ladeschritt (S1 009) zum Laden des *o 
ersten Protokollstapels; und 
einen Registrierungsschritt (S1010) zum 
Registrieren des ersten Protokollstapels 
mit dem Verbindungsunterstutzungs- 
schichtmodul (1 87), so dass der erste Pro- 45 
tokollstapel zukunftige Dateniibertra- 
gungsblockpakete empfangt, die mit dem 
ersten Datenubertragungsblocktyp uber- 
einstimmen. 
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support de liaison (S1 004) ; 
la reception, depuis ledit module de couche de 
support de liaison (1 87), d'un paquet de trames 
qui est adapts a un premier des types de 4. 
trames ; et 5 
le decodage d'une information d'en-tete dans 
le paquet de trames recu afin de determiner 
quel protocole est utilise par le paquet de tra- 
mes (S1007), 

le procede etant caracterise par les etapes qui 10 
consistent : 

5. 

a dSsenregistrer le premier type de trame 
dudit module de couche de support de 
liaison (S1008), ladite Stape de dSsenre- 15 
gistrement n'etant pas effectuee dans le 
cas ou le premier type de trame est un type 
de trame admissible pour une pile de pro- 
tocoles pas encore enregistrSe avec ledit 
module de couche de support de liaison 20 
(187); 

a initialiser une premiere pile de protocoles 
correspond ant au protocole determine en 
utilisant le premier type de trame ; 
a charger la premiere pile de protocoles 25 
(S1009) ; et 

a enregistrer la premiere pile de protocoles 
avec ledit module de couche de support de 
liaison (S1 01 0) afin que la premiere pile de 
protocoles recoive des paquets de trames 30 
futures qui concordent avec le premier type 
de trame. 



tocoles recoive des paquets de trames futures 
qui concordent avec le second type de trame. 

Procede selon la revendication 3, comprenant en 
outre les Stapes qui consistent a verifier le premier 
type de trame en regard du second type de trame 
et a signaler une erreur dans le cas ou ladite etape 
de decodage indique qu'une information d'en-tete 
decodee dans un second paquet de trames recu 
correspond a la premiere pile de protocoles. 

Dispositif pouvant fonctionner en reseau dans le- 
quel chacune d'une pluralite de piles de protocoles 
differentes communique sur un rSseau (100) par 
I'intermSdiaire d'un module commun de couche de 
support de liaison (187), comportant : 

une memoire (1 74) pour stocker des etapes de 
traitement, les Stapes de traitement compre- 
nant des etapes de traitement comprenant ledit 
module de couche de support de liaison (187) 
et des etapes de traitement comprenant ladite 
pluralite de piles de protocoles differentes ; et 
un processeur (1 73) destine a execute r les Sta- 
pes de traitement stockees dans ladite memoi- 
re, 

dans lequel les Stapes de traitement com- 
prennent en outre des Stapes de traitement pour 
enregistrer chacune de ladite pluralite de piles de 
protocoles diffSrentes avec ledit module de couche 
de support de liaison en : 



2. ProcSdS selon la revendication 1 , comprenant en 
outre I'Stape consistant a executer la premiere pile 35 
de protocoles afin de diffuser des communications 

de rSseau. 

3. ProcSdS selon la revendication 1 , comprenant en 
outre les Stapes qui consistent : 40 

a recevoir dudit module de couche de support 
de liaison un paquet de trames qui concordent 
avec un second des types de trames ; 
a dScoder une information d'en-tete dans le pa- 45 
quet de trames recu afin de dSterminer quel 
protocole est utilisS par le paquet de trames ; 
a dSsenregistrer le second type de trame dudit 
module de couche de support de liaison 

(51008) ; 50 
a initialiser une seconde pile de protocoles cor- 
respondent au protocole dSterminS en utilisant 

le second type de trame ; 

a charger la seconde pile de protocoles 

(51009) ;et 55 
a enregistrer la seconde pile de protocoles 
avec ledit module de couche de support de 
liaison (S1 01 0) afin que la seconde pile de pro- 



contrdlant des communications de rSseau dudit 
module de couche de support de liaison pour 
ta diffusion de paquets de trames, ledit module 
de couche de support de liaison (187) etant 
concu pour accepter des enregistrements pour 
Tun quelconque de plusieurs types de trames ; 
en registrant chacun des types de trames avec 
ledit module de couche de support de liaison 
(187); 

recevant dudit module de couche de support de 
liaison (187) un paquet de trames qui concor- 
dent avec un premier des types de trames ; et 
dScodant une information d'en-tete dans le pa- 
quet de trames regu afin de dSterminer quel 
protocole est utilisS par le paquet de trames, 
le dispositif Stant caracterise en ce que le pro- 
cesseur exScute les Stapes de traitement qui 
consistent : 

dSsenregistrer le premier type de trame a 
partir dudit module de couche de support 
de liaison (187), ladite Stape de dSsenre- 
gistrement n'Stant pas effectuSe dans un 
cas ou le premier type de trame est un type 
de trame admissible pour une pile de pro- 
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tocoles pas encore enregistree avec led it 
module de couche de support de liaison 
(187); 

initialiser une premiere pile de protocoles 
correspondant au protocole predetermine s 
en utilisant le premier type de trame ; 
charger la premiere pile de protocoles ; et 
enregistrer la premiere pile de protocoles 
avec ledit module de couche de support de 
liaison afin que la premiere pile de proto- io 
coles recoive des paquets de trames futu- 
res qui concordent avec le premier type de 
trame. 



6. Dispositif selon la revendication 5, comprenant en 15 
outre des etapes de traitement pour executer la pre- 
miere pile de protocoles afin de diffuser des com- 
munications de reseau. 

7. Dispositif selon la revendication 5, dans lequel les 20 
etapes de traitement comprennent en outre : 

la reception, depuis ledit module de couche de 
support de liaison (1 87), d'un paquet de trames 
qui concordent avec un second des types de 25 
trames ; 

le decodage d'une information d'en-tete dans 
le paquet de trames recu afin de determiner 
quel protocole est utilise par le paquet de 
trames ; 30 
le desenregistrement du second type de trame 
a partir dudit module de couche de support de 
liaison ; 

('initialisation d'une seconde pile de protocoles 
correspondant au protocole determine en utili- 35 
sant le second type de trame ; 
le chargement de la seconde pile de 
protocoles ; et 

I'enregistrement de la seconde pile de protoco- 
les avec ledit module de couche de support de 40 
liaison (187) afin que la seconde pile de proto- 
coles recoive des paquets de trames futures 
qui concordent avec le second type de trame. 

8. Dispositif selon la revendication 7, dans lequel les 45 
etapes de traitement comprennent en outre la veri- 
fication du premier type de trame en regard du se- 
cond type de trame et Vindication d'une erreur dans 

un cas ou ladite etape de decodage indique qu'une 
information d'en-tete decodee dans un second pa- so 
quet de trames recu correspond a la premiere pile 
de protocoles. 

9. Etapes de traitement executables par ordinateur 
pour determiner lequel d'une pluralite de protocoles 55 
differents est utilise sur un reseau, lesdites etapes 

de traitement comprenant : 



une etape d'execution (S1002) pour executer 
un module de couche de support de liaison 
(187) afin de controler les communications de 
reseau pour la diffusion de paquets de trames, 
ledit module de couche de support de liaison 
(187) etant concu pour accepter des enregis- 
trements pour Tun quelconque de plusieurs ty- 
pes de trames ; 

une etape d'enregistrement (S1004) pour en- 
registrer chacun des types de trames avec ledit 
module de couche de support de liaison (1 87) ; 
une etape de reception pour recevoir dudit mo- 
dule de couche de support de liaison (187) un 
paquet de trames qui concorde avec un pre- 
mier des types de trames ; 
une etape de decodage (S1007) pour decoder 
une information d'en-tete dans le paquet de tra- 
mes recu afin de determiner quel protocole est 
utilise par le paquet de trames, 
les etapes de traitement etant caracterisees 
par : 

une etape de desenregistrement (S1 008) 
pour desen registrar le premier type de tra- 
me a partir dudit module de couche de sup- 
port de liaison (1 87), ladite etape de desen- 
registrement n' etant pas effectuee dans le 
cas ou le premier type de trame est un type 
de trame admissible pour une pile de pro- 
tocoles pas encore enregistree avec ledit 
module de couche de support de liaison 
(187); 

une etape d'initialisation pour initialiser une 
premiere pile de protocoles correspondant 
au protocole determine en utilisant le pre- 
mier type de trame ; 

une etape de chargement (S1009) pour 
charger la premiere pile de protocoles ; et 
une etape d'enregistrement (S1010) pour 
enregistrer la premiere pile de protocoles 
avec ledit module de couche de support de 
liaison (187) afin que la premiere pile de 
protocoles recoive des paquets de trames 
futures qui concordent avec le premiertype 
de trame. 

10. Etapes de traitement executables par ordinateur 
selon la revendication 9, comprenant en outre une 
etape d'execution pour executer la premiere pile de 
protocoles afin de diffuser des communications de 
reseau. 

11. Etapes de traitement executables par ordinateur 
selon la revendication 9, comprenant en outre : 

une etape de reception pour recevoir dudit mo- 
dule de couche de support de liaison (187) un 
paquet de trames qui concorde avec un second 
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des types de trames ; 

une etape de decodage pour decoder une in- 
formation d'en-tete dans le paquet de trames 
recu afin de determiner que! protocole est utili- 
se par le paquet de trames ; s 
une etape de desenregistrement (S1008) pour 
desenregistrer le second type de trame a partir 
dudit module de couche de support de liaison ; 
une etape d'initialisation pour initialiser une se- 
conde pile de protocoles correspondant au pro- io 
tocole determine en utilisant le second type de 
trame ; 

une 6tape de chargement (S1009) pour char- 
ger la seconde pile de protocoles ; et 
une etape d'enregistrement (S1010) pour en- is 
registrer la seconde pile de protocoles avec le- 
dit module de couche de support de liaison 
(1 87) afin que la seconde pile de protocoles re- 
goive des paquets de trames futures qui con- 
cordent avec le second type de trame. 20 

12. Etapes de traitement executabtes par ordinateur 
selon la revendication 1 1 , comprenant en outre une 
etape de verification pour verifier le premier type de 
trame en regard du second type de trame et signa- 25 
ler une erreur dans le cas ou ladite etape de deco- 
dage indique qu'une information d'en-tete decoded 
dans un second paquet de trames recu correspond 
a la premiere pile de protocoles. 



13. Produit logiciel informatique stockant des etapes de 
traitement executables par ordinateur seion i'une 
quelconque des revendications 9 a 12. 
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